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Executive  Summary 

The  Infosphere  Concept  Exploration  and  Development  (ICED)  project,  conducted  by  ITT 
Corporation  under  contract  to  the  Air  Eorce  Research  Eaboratory  Information  Directorate 
(AERL/IE),  provides  concepts,  methods,  and  a  prototype  software  system  presenting  a 
Community  Of  Interest  (COI)  infosphere  with  a  consistent  vocabulary  definition 
capability.  As  information  management  systems  become  more  widely  used  by  COI, 
capabilities  are  increasingly  needed  to  easily  configure  such  systems  to  reflect  COI  needs 
and  vocabularies,  instead  of  those  of  a  single  predefined  organization.  High  operation 
tempos  demand  equally  responsive  information  systems  that  can  be  composed,  dissolved 
and  reconfigured  to  match  the  changing  nature  of  the  information  battlespace. 

The  result  of  this  effort  is  a  proof-of-concept  technology  enabling  and  supporting  the 
instantiation,  integration,  and  operation  of  information  management  tools  within  and 
across  COIs.  Results  include: 

•  A  prototype  Type  Management  System  (TMS)  to  support  a  COI  information 
engineer  in  defining  XSDs  for  use  in  COI  information  management 

•  An  iterative  and  hierarchical  schema  development  process  supported  by  the  TMS 

•  A  scenario  and  a  demonstration  of  the  TMS  operating  under  that  scenario 

•  Directions  identified  for  future  research  for  the  development  of  the  TMS  and  the 
schema  processes  supported  by  the  TMS. 

Schemas  developed  and  maintained  with  the  TMS  are  represented  in  a  hierarchy  with 
four  levels.  Base  Data  Types,  function  as  (non-user  managed)  atomic  primitives. 

Elements  combine  a  base  Data  Type  and  a  description  of  each  Element’s  meaning. 
Eragments  represent  discrete  sets  of  COI  information  in  terms  of  combinations  of 
Elements  and  sub-Eragments.  Eragments  and  Elements  are  combined  into  models;  each 
Model  can  generate  an  XML  Schema  Definition  (XSD).  XSDs  can  be  used  to  configure 
information  management  tools.  The  capability  to  define  reusable  Models,  Eragments,  and 
Elements  allows  the  TMS  user  to  specify  information  objects  and  their  components 
processed  within  and  between  COIs. 

The  TMS  provides  two  interfaces  to  users.  The  Graphical  User  Interface  (GUI)  to  the 
TMS,  an  Eclipse  plugin,  supports  the  creation  and  management  of  Elements,  Eragments, 
and  Models.  The  GUI  provides  a  concise  visual  display  of  the  construction  of  schemas. 
The  Web  Services  interface  to  TMS  provides  an  automated  capability  to  fetch  XSDs 
created  by  the  TMS.  ITT  envisions  that  other  information  management  tools  will  use  the 
Web  Services  in  machine-to-machine  interactions. 

An  overall  goal  of  the  project  was  to  demonstrate  the  feasibility  of  a  functional,  capable 
tool  supporting  COI  information  engineers  and  abstracting  computer  science,  XML,  and 
XSD  knowledge  from  the  user,  thereby  enabling  COI  information  engineers  to  focus  on 
application  area  issues.  ITT  found  that  this  goal  can  be  attained  if  the  tool  functionality  is 
limited,  but,  as  capabilities  are  added  to  the  tool,  the  user  is  increasingly  likely  to  be 
required  to  know  specific  aspects  of  XML,  XSD,  and  computer  science. 
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The  TMS  and  its  demonstration  show  that  COI  information  engineers  configuring  and 
reconfiguring  information  management  tools  can  benefit  from  automated  software  tool 
support.  The  prototype  support  provided  by  the  TMS  can  be  improved  by  future  research 
in  expansion  of  TMS  support  to  additional  features  of  the  XSD  language,  additional 
capabilities  to  the  TMS  GUI,  additional  capabilities  of  the  TMS  Web  Services,  additional 
TMS  capabilities  particularly  in  TMS  data  storage,  and  expansion  of  TMS  usefulness  in 
process  support  and  in  the  environment  in  which  the  TMS  operates.  This  report  provides 
suggestions  of  future  research  directions  in  each  of  these  five  areas. 


1.0  Introduction 

This  document  is  the  final  report  for  the  Infosphere  Coneept  Exploration  and 
Development  (ICED),  a  research  project  conducted  by  ITT  Corporation,  Advaneed 
Engineering  and  Sciences  Division,  under  eontract  to  the  Air  Eorce  Research  Eaboratory, 
Information  Directorate  (AERL/IE). 


1.1  Background 

The  Air  Eorce  Research  Eaboratory,  Information  Directorate  (AERE/IE)  investigates, 
develops,  maintains,  and  enhances  Operational  Information  Management  (OIM) 
eapabilities.  OIM  is  a  Net-Centrie  information  management  program.  Information 
Management  concepts  are  being  implemented  in  various  software  architeetures  and 
systems  that  provide  supporting  infrastructure.  The  DoD  Metadata  Registry  (DDMR), 
Information  Management  Core  Services  (IMCS),  and  Net-Centric  Enterprise  Services 
(NCES)  are  examples  of  sueh  Information  Management  infrastructure,  of  whieh  the  IMC 
Services  is  implemented  under  the  OIM  program.  AERE/IESE  continues  to  explore  tools, 
eoneepts,  and  processes  supporting  the  ereation  and  management  of  stable  and  consistent 
infospaces  for  Communities  of  Interest  (COIs). 

A  Community  Of  Interest  (COI)  is  a  group  of  users  who  collaborate  on  a  set  of  tasks.  The 
members  of  a  COI  may  come  from  multiple  organizations.  Eor  example,  a  COI  with  a 
military  applieation  might  include  members  from  multiple  serviees  or  personnel  from 
defense  organizations  under  multiple  governments.  A  COI  needs  a  shared  vocabulary  to 
describe  and  share  information  among  COI  members  and  with  other  organizations.  As 
Information  Management  systems  become  more  widely  used  by  COIs,  capabilities  are 
being  inereasingly  demanded  to  easily  configure  such  systems  to  reflect  COI  needs  and 
voeabulary,  instead  of  those  of  a  single  predefined  organization. 

The  IMCS  Metadata  Schema  Repository  and  Information  Object  Repository  provides  a 
capability  in  which  XML  Schema  Deseriptions  (XSDs)  are  used  to  define  information 
objects.  The  development  of  an  XSD,  however,  requires  fairly  sophisticated  teehnical 
abilities.  Eurthermore,  it  is  difficult  to  browse  XSDs  and  easily  eompare  and  contrast  how 
different  information  objects  are  defined.  Capabilities  are  needed  to  provide  personnel 
that  have  speeialized  application  knowledge,  but  less  advanced  eomputer  seienee 
technieal  knowledge,  methods  and  proeesses  for  configuring  Information  Management 
systems  to  satisfy  COI  needs. 

Analysts  designing  information  objects  for  a  COI,  and  their  associated  sehemas,  draw  on 
either  an  informal  or  formal  representation  of  the  domain  from  which  information  objects 
can  come.  This  representation  may  include  some  notion  of  the  individuals  comprising  the 
domain  of  diseourses,  the  classes  or  sets  into  whieh  these  individuals  fall,  attributes  that 
can  describe  individuals,  and  relations  between  individuals,  classes,  etc.  In  other  words, 
the  development  of  schemas  for  a  COI  falls  within  the  diseipline  of  ontological 
engineering.  An  ontology: 
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“is  a  hierarchically  structured  set  of  terms  for  describing  a  domain  that  can 
be  used  as  a  skeletal  foundation  for  a  knowledge  base.”  (Swartout  et  al. 

1997,  as  quoted  in  Gomez-Perez  et  al.  2004) 

“An  ontology  may  take  a  variety  of  forms,  but  it  will  necessarily  include  a 
vocabulary  of  terms  and  some  specification  of  their  meaning.  This 
includes  definitions  and  an  indication  of  how  concepts  are  inter-related 
which  collectively  impose  a  structure  on  the  domain  and  constrain  the 
possible  interpretations  of  terms.”  (Uschold  and  Jasper  1999,  as  quoted  in 
Gomez-Perez  et  al.  2004) 

Researchers  in  Knowledge  Engineering,  Artificial  Intelligence,  and  Computer  Science 
increasingly  find  it  useful  to  explicitly  represent  ontologies  in  a  formal  language.'  For 
example,  the  Web  Ontology  Language  (OWL,  see  http://www.w3.org/TR/owl-features/) 
is  an  extension  of  XML  to  support  the  specification  of  ontologies.  Furthermore, 
researchers  in  these  fields  have  developed  methods,  methodologies,  and  tools  for 
constructing,  merging,  evaluating,  and  otherwise  managing  ontologies.  For  example. 
Protege  (http://protege.stanford.edu/)  “is  a  free,  open  source  ontology  editor  and 
knowledge-base  framework”.  As  another  example,  Jena  (http://iena.sourceforge.net/ 
ontology/)  provides  a  Java-based  Application  Programming  Interface  (API)  supporting 
the  development  of  applications  within  the  semantic  web. 

The  OIM  program  has  identified  a  need  to  provide  ontological  engineering  capabilities  to 
analysts  setting  up  Information  Management  capabilities  for  a  COL  Such  analysts  may  be 
presumed  to  have  a  general  technical  background,  but  cannot  be  assumed  to  have 
completed  training  in  XML,  XSD,  or  tools  and  languages  supporting  ontological 
engineering.  The  research  described  in  this  report  fills  this  need  by  demonstrating  a 
software  system  and  processes  to  provide  these  capabilities. 


1.2  Purpose 

The  work  described  in  this  report  provides  concepts,  methods,  and  a  prototype  software 
system  presenting  a  COI  infosphere  with  a  consistent  vocabulary  definition  capability. 
An  overall  goal  of  the  project  was  to  demonstrate  the  possibility  of  a  functional,  capable 
tool  supporting  COI  information  engineers  and  abstracting  computer  science,  XML,  and 
XSD  knowledge  from  the  user.  ITT  wanted  to  develop  a  user-friendly  tool  for  COI  staff 
without  an  XML  expert  available.  Specifically,  this  effort: 

•  Developed  a  method  for  defining  a  COI’s  vocabulary  using  primitive  terms: 
o  The  software  system  provides  a  Type  Management  System  (TMS)  in  which 
base  Data  Types  function  as  (non-user  managed)  atomic  primitives 


*  Quine  (1953)  is  an  early  case  in  philosophy  of  analyzing  formal  languages  to  clarify  ontological 
commitments.  Quine’s  slogan,  “To  be  is  to  be  the  value  of  a  bound  variable”  concisely  states  that  the  sets 
of  objects  which  quantified  variables  can  range  over  in  statements  of  the  predicate  calculus,  such  as 
Vx,  p{x) ,  constitute  those  individuals  whose  existence  is  postulated  by  an  analysis  of  statements. 
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o  The  software  system  supports  a  proeess  for  ereating  a  COI-speeifie 

voeabulary  of  Elements  in  the  TMS,  where  an  Element  eombines  a  base  Data 
Type  and  a  deseription  of  the  Element’s  meaning 
o  The  software  system,  assoeiated  doeumentation,  and  assoeiate  proeesses 
provides  eapabilities  to  manage  the  COI-speeifie  voeabulary 

•  Developed  a  proeess  for  defining  sehemas  using  the  COI’s  defined  voeabulary 

o  The  software  system  supports  representing  diserete  sets  of  COI  information  in 
terms  of  eombinations  of  primitive  terms;  these  eombinations  are  the 
Eragments  in  the  TMS 

o  The  software  system  supports  eombining  Eragments  and  Elements  into 
Models,  whieh  in  turn  ean  be  used  to  generate  XML  Sehema  Definitions 
(XSDs).  These  XSDs  are  eompatible  with  the  IMCS,  as  well  as  with  other 
systems. 

•  Developed  a  software  system  enabling  elients  to  define  COI  voeabulary  and  to 
eonstruet  XSDs  in  aeeordanee  with  the  COEs  ontologieal  requirements 

o  The  Graphieal  User  Interfaee  (GUI)  to  the  TMS,  an  Eelipse  plugin,  supports 
the  ereation  and  management  of  the  primitive  Elements  in  a  COI-speeifie 
voeabulary 

o  The  GUI  allows  for  the  visual  display  of  the  eonstruetion  of  sehemas  through 
the  ereation  and  management  of  Eragments  and  Models,  eomprised  of 
Elements  and  Eragments 

o  The  Web  Serviee  (WS)  interfaee  to  the  software  system  provides  the  TMS 
with  a  eapability  to  feteh  XSDs  generated  by  the  COI,  whieh  ean  then  be  used 
in  other  systems,  sueh  as  the  IMCS  Metadata  Sehema  Repository  (MSR) 

•  Demonstrated  the  newly  developed  eapabilities  for  this  effort,  as  eneapsulated  in 
the  TMS 

o  The  demonstration,  as  exhibited  at  the  effort’s  final  presentation  and 
deseribed  in  Seetion  3.3  of  this  report,  is  defined  in  the  eontext  of  an 
operationally  realistie  scenario 

o  The  setup,  initialization,  and  execution  of  the  demonstration  are 
documented  in  this  report. 

1.3  Scope 

As  part  of  a  grander  vision  of  composable  Infospaces,  the  scope  of  this  effort  is  to  design 
and  develop  methods,  processes  and  software  that  provide  a  consistent  vocabulary 
management  capability  to  COI  members  and  administrators. 


1.4  Synopsis  of  Report  Organization 

The  remainder  of  this  report  is  subdivided  into  two  main  sections  and  followed  by  a 
conclusion. 

Section  2,  titled  “Methods,  Assumptions,  and  Procedures”,  describes  the  tasks  conducted 
under  this  effort  to  achieve  ITT’s  research  results.  Section  2  describes  the  development  of 
methods  for  defining  a  COI-speeifie  vocabulary,  of  processes  for  defining  schemas,  of 
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software  to  provide  automated  support  for  these  methods  and  proeesses,  and  of  a 
demonstration  of  that  tool.  Seetion  2  also  briefly  deseribes  the  management  of  the  ICED 
projeet. 

Seetion  3,  title  “Results  and  Discussion”,  describes  the  research  results  achieved  under 
this  effort.  Results  fall  into  three  main  categories: 

•  The  Type  Management  System  (TMS) 

•  The  specification  of  schema  development  processes  supported  by  the  TMS 

•  The  definition  of  a  scenario  with  which  the  TMS  is  demonstrated 

Section  3  describes  results  in  each  of  these  areas.  As  part  of  the  description  of  the  TMS, 
instructions  are  provided  for  deploying  and  executing  the  software. 

The  conclusion  section  summarizes  the  accomplishments  of  this  effort  and  directions  for 
future  research. 
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2.0  Methods,  Assumptions,  and  Procedures 

The  methods  and  proeedures  ITT  adopted  under  the  ICED  projeet  fall  into  four  tasks: 


•  Develop  a  method  for  defining  a  voeabulary  for  a  Community  Of  Interest  (COI) 

•  Develop  a  proeess  for  defining  schemas  for  information  objects 

•  Develop  the  Type  Management  System  (TMS) 

•  Develop  a  demonstration  of  the  TMS 

This  section  describes  the  activities  conducted  under  each  one  of  these  tasks.  This  section 
also  briefly  overviews  aspects  of  ICED  project  management. 


2.1  Develop  Method  for  Defining  a  Vocabulary 

ITT  investigated  how  a  vocabulary  for  a  COI  would  be  used.  In  the  context  of 
information  management,  the  terms  in  a  COI  vocabulary  are  the  names  of  information 
objects  and  parts  of  information  objects.  In  particular,  a  vocabulary  would  be  used  to 
describe  information  objects  in  terms  of  metadata  schemas.  Schemas  and  parts  of 
schemas  support  searches  (Harlow  2005)  and  the  population  of  Metadata  Registries 
(ISO/IEC  2004),  such  as  the  DoD  Metadata  Registry  (DDMR),  and  of  the  Metadata 
Schema  Repository  (MSR)  associated  with  the  Information  Management  Core  Services 
(IMCS). 

2.1.1  Create  terminology 

Under  the  ICED  project,  a  hierarchical  structure  was  created  in  which  the  vocabulary  for 
a  COI  can  be  formalized.  Terminology  was  invented  to  describe  terms  on  each  level  of 
this  hierarchy: 

•  Data  Types,  originally  called  “Atomic  Primitives”,  are  the  lowest  level  in  the 
hierarchy  and  are  predefined 

•  Elements,  originally  called  “Complex  Primitives”,  are  basic  building  blocks  of  a 
COI  vocabulary 

•  Eragments  are  composed  of  Elements  and  other  Eragments. 

•  Models,  originally  called  “Schemas”,  are  the  highest  level  of  the  hierarchy,  are 
composed  of  Elements  and  Eragments,  and  are  used  to  generate  XML  Schema 
Definitions  (XSDs). 

2.1.2.  Adopt  base  set  of  Data  Types 

The  base  set  of  Data  Types  were  selected  from  the  data  types  defined  in  XSD.  These 
types  were  selected  to  illustrate  how  more  complex  notions  can  be  built  on  top  of  this 
base  in  defining  a  COI  vocabulary. 
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2.1.3  Develop  a  method  for  creating  a  COI-specific  vocabulary 

Once  the  hierarehy  of  terms  was  defined,  one  ean  explore  how  a  COI  voeabulary  can  be 
ereated  and  struetured  in  this  hierarehy.  In  partieular,  the  use  of  subfragments,  as  children 
of  Fragments,  allows  any  level  of  depth  to  be  supported  by  this  hierarehieal  method.  Tool 
support  is  easier  to  provide  if  the  hierarehieal  method  is  eonfined  to  produeing  a  Direeted 
Aeyclie  Graph  (DAG),  and  that  eonstraint  was  imposed  on  the  prototype  produced  under 
this  project. 

Section  3.1.1  provides  further  details  about  Data  Types,  Elements,  Fragments,  and 
Models. 


2.2  Develop  a  Process  for  Defining  Information  Object  Type 
Schemas 

In  speeifying  a  proeess  for  defining  schemas,  ITT  researehers  drew  on  the  literature  in 
ontologieal  engineering  and  in  software  engineering  lifecyele  models.  Gomez-Perez  et  al. 
(2004)  discusses  how  ontology  development  proeesses  fit  into  a  larger  set  of  proeesses, 
including  management  and  support  proeesses.  The  sehema  proeesses  were  defined  in  an 
analogous  eontext.  Furthermore,  sehema  development  was  eonceptualized  as  a  set  of 
iterative  proeesses.  Iterative  or  spiral  lifeoyele  proeesses  have  been  used  in  software 
engineering  for  some  time  (Boehm  1988).  Top-down  and  bottom-up  proeesses  are  well- 
established  metaphors  in  software  engineering,  and  these  metaphors  were  drawn  on  for 
further  speeifying  schema  development  proeesses.  Sehema  proeesses,  including  schema 
development  proeesses,  are  more  fully  defined  in  Seetion  3.2 


2.3  Develop  Type  Management  System 

ITT  developed  a  software  system,  the  Type  Management  System  (TMS),  under  the  ICED 
projeet.  ITT  met  with  AFRE  during  the  ICED  kickoff  meeting  to  elarify  the  role  and 
purpose  of  the  TMS.  This  elarifieation,  and  the  definition  of  terms  and  individual  pieees 
of  the  TMS,  solidified  the  eoneepts  and  high-level  arehiteeture  of  the  TMS. 

In  particular,  ITT  and  AFRE  agreed  that  the  TMS  is  a  repository  for  Elements, 
Fragments,  and  Models  that  represent  information  relevant  to  Communities  of  Interest 
(COI).  The  TMS  has  a  Graphieal  User  Interfaee  (GUI)  that  allows  users  to  ereate, 
modify,  and  delete  that  information.  The  TMS  presents  appropriate  serviees  to  the 
eommunity  via  a  Web  Serviee  layer.  With  this  eapability,  the  TMS  eould  serve  as  the 
Metadata  Sehema  Repository  in  a  Net-Centrie  Information  Management  System,  sueh  as 
Information  Management  Core  Serviees  (IMCS)  implementations.  ITT  and  AFRE  also 
agreed  that  a  secondary  goal  of  the  TMS  is  to  provide  enough  ontological  support  so  that 
users  ean  eonvey  the  meaning  of  their  COEs  information. 

ITT  investigated  the  Web  Ontology  Eanguage  (OWL),  Protege,  and  Jena,  whieh  are 
teehnologies  that  ean  be  leveraged  in  developing  ontology  tools.  Both  Protege  and  Jena 
can  be  used  inside  Eelipse.  ITT  installed  and  experimented  with  both  using  simple 
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models.  Since  IMS  storage  was  designed  as  XML  flat  fdes,  use  of  Protege  and  Jena 
would  be  overkill  for  the  ICED  project.  These  advanced  technologies  may  be  used  in 
future  work  adding  advanced  ontology  capabilities  to  the  IMS.  For  example,  Jena  could 
be  used  with  the  TMS  model  if  capabilities  to  manipulate  OWL  schemas  are  desired. 

This  experimentation  helped  establish  that  the  TMS  development  would  focus  on  initial 
storage  capabilities,  a  Web  Services  interface,  and  a  GUI. 


2.3.1  TMS  Storage 

The  TMS  allows  the  user  to  define  Elements,  Fragments,  and  Models.  The  TMS 
generates  XSD  files.  The  Elements,  Fragments,  and  Models  must  be  stored  in  an 
intermediate  form  to  support  user  definitions  and  management.  ITT  researched  repository 
solutions  and  implemented  a  prototype  TMS  storage  solution. 

For  example,  ITT  looked  at  the  Berkeley  XML  Database  (XMLDB).  After  research  on 
the  stability  and  maturity  of  XMLDB,  ITT  decided  that  this  project  would  not  benefit 
from  implementing  a  solution  based  on  an  XMLDB.  ITT  also  looked  at  using  Jena  as  the 
database  interface  to  a  MySQL  Database. 

ITT  decided  that,  for  initial  capabilities  produced  under  this  project,  TMS  storage  would 
use  simple  file  system  storage  mechanisms.  ITT  did  not  implement  a  solution  using  a  full 
relational  or  XML  database.  This  decision  sped  up  development  and  allowed  ITT  to  focus 
on  prototype  functionality  instead  of  working  on  underlying  database  infrastructure.  The 
TMS  storage  capabilities  are  further  described  in  Section  3.1.2. 


2.3.2  Web  Services  Development 

Under  the  direction  of  AFRL,  the  development  of  the  TMS  was  decoupled  from  IMCS 
dependencies.  The  TMS  provides  a  capability  for  information  management  tools  (IMCS, 
NCES  Discovery  Services,  etc.)  supporting  COIs  to  retrieve  XML  schemas  created  with 
the  TMS.  That  is,  the  Web  Services  interface  to  the  TMS  provides  Web  Services  to 
access  schemas  generated  by  the  TMS. 

ITT  began  Web  Services  development  by  implementing  skeletal  Web  Services.  ITT 
expanded  and  refined  these  over  the  course  of  the  project.  ITT  explored  some  Web 
Services  capabilities  that  could  be  implemented  in  further  work.  For  example,  ITT 
researched: 

•  The  use  of  Simple  API  for  XMF  (SAX)  and  Document  Object  Model  (DOM) 
libraries  and  constructed  preliminary  methods  to  provide  a  capability  to  search  the 
contents  of  XSD  files 

•  The  construction  of  a  demonstration  client  for  a  Web-based  front  end  to  TMS, 
providing  schema-based  searching  on  either  a  Java  console  application  or  as  a 
Web  application  using  the  same  Web  Services.  This  research  included 
experimentation  with  Ruby  on  Rails. 
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At  the  completion  of  the  project,  the  TMS  Web  Services  provided  capabilities  to: 

•  Retrieve  XSDs  by  name 

•  Retrieve  a  list  of  XSDs  in  a  specified  directory 

•  Search  for  names  of  XSDs  based  on  a  partial  name 

The  TMS  Web  Services  are  more  fully  described  in  Section  3.1.4. 


2.3.3  GUI  Development 

At  the  ICED  kickoff  meeting,  ITT  described  plans  to  implement  the  TMS  GUI  in  the 
Eclipse  framework.  In  keeping  with  these  plans,  ITT  programmers  explored  the  Standard 
Widget  Toolkit  (SWT)  -  which  is  a  Java-based  GUI  development  framework  used  in 
Eclipse,  Eclipse  application  development,  and  the  Eclipse  plug-in  architecture.  The  TMS 
GUI  displays  Elements,  Eragments,  and  Models.  (Originally,  “Models”  were  called 
“Schemas”.)  Properties,  corresponding  to  XSD  “Attributes”,  can  be  added  to  Eragments 
and  Models.  ITT  used  the  GUI  development  as  the  driver  for  defining  the  underlying 
logic  for  maintaining  Elements,  Eragments,  and  Models. 

In  Eebruary  2006,  ITT  conducted  a  Technical  Interchange  Meeting  (TIM)  with  AERL  in 
which  various  project  decisions  were  discussed  and  debated.  It  was  at  this  meeting  that 
the  distinction  between  Eragments  and  Models  was  introduced  into  the  TMS  design. 
Another  topic  of  discussion  was  how  changes  made  in  the  GUI  would  affect  existing 
XSDs.  That  is,  matching  XSDs  would  be  updated  when  an  Element,  Eragment,  or  Model 
is  changed  through  the  GUI. 

The  development  of  the  TMS  GUI  continued  to  progress  after  the  TIM.  Capabilities 
added  to  the  GUI  include: 

•  The  generation  of  XSD  from  a  Model  and  the  saving  of  the  XSD  to  a  file 

•  The  updating  of  any  matching  XSD  when  an  Element,  Eragment,  or  Model  is 
changed 

•  Some  drag-and-drop  functionality  -  dragging  an  Element  to  a  Eragment  or  Model, 
dragging  a  Eragment  under  another  Eragment,  and  dragging  a  Eragment  to  a 
Model  now  all  modify  the  hierarchy  of  user-defined  Elements,  Eragments,  and 
Models  appropriately 

•  A  “View  XSD”  feature 

•  The  listing  of  the  Eragments  and  Models  in  which  a  user-specified  Element  is 
used 

•  The  sorting  of  Elements 

•  The  addition  of  Properties  to  Eragments  and  Models 

•  A  robust  “Help”  feature,  including  the  addition  of  many  Help  topics 

•  The  capture  of  the  time  and  user  when  Elements,  Eragments,  or  Models  are 
updated 
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•  Finer-grained  logging  to  reeord  user  modifieations 

Developing  the  IMS  GUI  ineluded  many  details  neeessary  to  produee  a  working  system. 
For  example,  the  eode  eonstrains  the  deeomposition  of  Fragments  to  be  a  loop-free  tree, 
thereby  avoiding  infinite  loops  in  the  eode.  Some  effort  was  expended  towards  the  end  of 
the  projeet  in  researehing  how  to  deploy  the  GUI  as  an  Eelipse  plugin.  The  eode  was 
doeumented  and  Javadoes  were  generated  for  all  IMS  classes.  ITT  conducted  much 
informal  testing  throughout  the  development  process.  A  number  of  known  schemas  were 
generated  with  the  tool  as  part  of  the  testing.  The  TMS  GUI  is  more  fully  described  in 
Section  3.1.3. 


2.4  Demonstrate  the  TMS 

The  TMS  is  a  proof-of-concept  system  intended  to  show  the  utility  of  providing  COI 
information  engineers  with  capabilities  to  model  the  structure  of  COI  information  objects 
and  to  generate  schemas.  As  such,  developing  a  demonstration  of  the  use  of  the  TMS  was 
an  important  part  of  the  ICED  project. 

ITT  presented  two  demonstrations  of  the  TMS  during  this  project.  The  first  was  a 
presentation  at  the  Operational  Information  Management  (OIM)  Principal  Investigator 
(PI)  meeting  in  April  2006.  The  TMS  software  was  deployed  for  this  presentation  to  run 
off  a  flash  drive.  The  focus  of  this  demonstration  was  to  illustrate  some  capabilities  of  the 
TMS,  as  it  stood  at  that  stage  of  the  project. 

ITT  demonstrated  the  TMS  as  part  of  the  ICED  final  presentation  in  September  2006. 
This  demonstration  was  presented  in  the  context  of  a  user-oriented  scenario,  in  which  a 
COI  information  engineer  uses  the  TMS  to  create  a  Cursor-On-Target  (COT)  XSD  file  to 
configure  COI  information  management  tools.  As  such,  the  scenario  and  demonstration 
provide  a  context  in  which  schema  processes  can  be  discussed.  The  demonstration 
scenario  and  TMS  demonstration  is  more  fully  described  in  Section  3.3. 


2.5  Project  Management 

Project  management  activities  performed  by  ITT  during  this  task  included  status 
reporting  and  meetings  with  AERL/IE.  Table  2-1  lists  major  meetings  with  AERL/IE 
participation. 


Table  2-1:  ICED  Meetings 


Review 

Date 

Kickoff  Meeting 

17  October  2005 

Technical  Interchange  Meeting  (TIM) 

3  Pebruary  2006 

Presentation  at  OIM  PI  Meeting 

11-12  April  2006 

Status  Review  Meeting 

23  May  2006 

Status  Review  Meeting 

15  June  2006 

Pinal  Presentation 

15  September  2006 

At  the  kickoff  meeting,  ITT  assisted  in  defining  the  requirements  for  the  TMS.  A 
discussion  of  current  research  on  ontologies  and  AFRL/IF  feedback  on  the  tasks  in  the 
Statement  of  Work  (SOW)  helped  clarify  the  scope  of  the  ICED  project.  ITT  and 
AFRL/IF  agreed  that  basic  terms  of  the  TMS  include  “Data  Type”,  “Element”,  and 
“Eragment”. 

ITT  prepared  and  presented  slides  at  the  Eebruary  TIM.  ITT  discussed  project  progress 
and  reported  no  obstacles  to  progress  existed  in  the  ICED  project. 

ITT  personnel  participated  in  the  OIM  PI  meeting  held  April  11-12  in  Washington,  DC. 
ITT  presented  a  poster  session,  a  demonstration,  and  a  slide  show. 

ITT  met  with  AERL/IE  on  23  May  to  discuss  the  tasks  to  be  completed  before  the  end  of 
the  contract.  ITT  and  AERL/IE  agreed  that  they  would  hold  another  meeting  to  discuss 
the  priority  of  enhancements  extending  the  ICED  scope  if  the  tasks  identified  in  the  SOW 
were  completed  without  depleting  the  funding. 

This  additional  meeting  was  held  on  15  June.  ITT  and  AERL/IE  discussed  the  project 
tasks  as  outlined  in  the  statement  of  work.  Eor  those  tasks  that  were  incomplete,  ITT  and 
AERL/IE  agreed  on  a  path  to  completion. 

At  the  final  presentation,  ITT  presented  the  results  of  this  effort.  Results  included  a 
description  of  the  benefits  of  using  the  TMS,  of  directions  for  future  research,  of  schema 
definition  processes,  and  of  the  scenario  for  the  demonstration.  The  TMS  was 
demonstrated  at  the  final  presentation. 


9 


3.0  Results  and  Discussion 

Under  the  ICED  project,  ITT; 


•  Produced  a  prototype  Type  Management  System  (TMS)  to  support  a  Community 
Of  Interest  (COI)  information  engineer  defining  information  objects  to  be  used  in 
COI  information  management 

•  Identified  schema  processed  and  defined  schema  development  processes 
supported  by  the  TMS 

•  Defined  a  scenario  and  produced  a  demonstration  of  the  TMS  operating  under  that 
scenario. 

Each  one  of  these  results  is  discussed  in  a  subsection  of  this  section. 


3.1  Type  Management  System 

The  Type  Management  System  (TMS)  is  comprised  of  three  major  subsystems; 

•  XML  files  for  storing  Elements,  Eragments,  Models,  and  Schemas  manipulated 
by  the  TMS 

•  A  Graphical  User  Interface  (GUI),  deployed  as  an  Eclipse  plugin 

•  TMS  Web  Services  for  accessing  and  retrieving  XML  Schemas  created  by  the 
TMS. 

After  an  overview  of  the  TMS,  each  major  subsystem  is  described  in  a  subsection  of  this 
section. 


3.1.1  Type  Management  System  Overview  and  Vocabulary 

The  TMS  is  designed  to  support  a  user  defining,  modifying,  or  configuring  schemas  for 
Information  Management  tools.  These  Information  Management  tools  are  assumed  to  be 
capable  of  providing  infrastructure  for  a  Community  Of  Interest  (COI).  The  TMS 
provides  capabilities  for  describing  information  objects  that  flow  between  and  within 
such  COI  tools.  In  effect,  the  TMS  allows  the  user  to  build  and  maintain  a  vocabulary  for 
a  COI,  where  the  words  in  the  vocabulary  can  range  over  the  names  of  these  information 
objects  and  of  parts  of  these  objects. 

The  TMS  GUI  provides  a  user  with  a  capability  to  create  and  browse  a  compact 
description  of  potentially  complex  XML  Schema  Definitions  (XSDs).  Liles  containing 
XSDs  can  be  generated  from  Models  in  the  TMS,  while  Eragments  and  Elements  provide 
reusable  components  of  Models.  These  XSD  files,  in  turn,  can  be  used  to  configure 
Information  Management  tools,  such  as  IMCS  andNCES  servers  and  clients. 
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The  TMS  user  is  assumed  to  be  a  COI  information  user.  The  user  is  assumed  to  have 
domain  knowledge,  where  the  domain  would  vary  with  the  speeific  COI  and  the 
applications  supported  within  that  COI.  For  example,  in  the  scenario  developed  under  this 
project  to  demonstrate  TMS  capabilities,  the  user  is  assumed  to  have  some  knowledge  of 
tactical  military  applications.  The  backend  of  the  TMS  draws  heavily  on  XML  and  XSD 
standards  and  technology.  The  TMS  user,  however,  need  not  understand  either  XML  or 
XSD  syntax.  The  TMS  user  is  assumed  to  have  some  introductory  computer  science 
knowledge.  Specifically,  the  user  is  assumed  to  be  aware  that  variables  are  typed;  to 
recognize  type  names,  such  as  float  and  integer;  and  to  be  able  to  decide  what  types  are 
appropriate  for  Elements  and  Properties  the  user  defines  within  the  TMS. 

The  Type  Management  System  (TMS)  is  organized  around  a  hierarchy  of  user-defined 
Elements,  Eragments,  and  Models.  Elements  are  defined  in  terms  of  given  Data  Types, 
and  XME  Schema  Definitions  (XSDs)  are  generated  from  Models.  This  overview  of  the 
TMS  explains  what  Data  Types,  Elements,  Eragments,  Models,  and  Schemas  are. 


3. 1.1.1  Data  Type 

A  Data  Type,  in  the  TMS,  is  a  low-level  basic  component  of  a  COI  vocabulary.  Data 
Types  have  no  semantics  associated  with  them,  other  than  some  general  mathematical 
and  calendar  knowledge.  The  TMS  currently  has  the  following  Data  Types  defined: 
string,  integer,  nonNegativeInteger,  positiveinteger,  decimal,  float,  date,  time,  dateTime. 
These  are  a  subset  of  Data  Types  defined  in  standard  XSD.  Data  Types  are  used  by  TMS 
users  creating  Elements  and  assigning  Properties  to  Eragments  or  Models,  but  are  not 
explicitly  managed  by  TMS  users. 


3. 1.1.2  Element 

An  Element  is  a  higher-level  object  than  a  Data  Type.  Elements  are  the  basic  building 
blocks  of  the  TMS,  representing  the  smallest  or  atomic  unit  of  information  managed  by 
the  TMS  user.  An  Element  consists  of  a  Name,  Data  Type,  and  Description.  These  three 
fields  are  required.  The  TMS  also  contains  information  on  when  and  by  whom  each 
Element  was  created  and  last  modified.  With  the  mandatory  fields  in  an  Element, 
Elements  describe  a  data  item  with  semantic  information  not  present  in  Data  Types 
(Eigure  3-1). 

An  Element’s  Name  must  be  unique  across  the  TMS.  No  other  Element,  Eragment,  or 
Model  can  have  the  same  Name.  Names  should  be  chosen  to  be  meaningful  to  others 
within  the  COL  The  Element’s  Description  should  explain  the  Element’s  purpose  and  use 
in  enough  detail  to  be  understandable  to  others  in  the  COL  The  reuse  of  Elements, 
Eragments,  and  Models  is  a  goal  of  the  TMS,  and  the  Description  of  an  Element  should 
support  such  reuse. 
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3. 1.1.3  Fragment 

Fragments  are  snippets  of  the  COI-speeifie  language  that  is  being  defined.  Fragments  are 
eomposed  of  Elements  and  other  Fragments.  Fragments  differ  from  Models  in  that 
Fragments  are  ineomplete,  whereas  Models  are  a  finished  product.  Models  can  be  used  to 
generate  XML  Schemas,  but  Fragments  cannot. 


Figure  3-1:  Data  Types  Contrasted  With  Elements 


Fragment:  Address 

Name:  Address 

Description:  US  Postal  Service 
address 

Properties:  None  / 

Child  Grouping:  Required  tdoe 
in  the  sequence  display^ 

CstreetAddressX 


d  city 


country 


Element:  streetAddress _ 

Description:  US  Post  Office  street 
address 

Data  Type:  string 

Element:  city _ 

Description:  Name  of  city 

Data  Type:  string 

Element:  state 


Description:  Full  state  name 
Data  Type:  string 


Element:  count 


Description:  Full  country  name 


Data  Type:  string 
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A  Fragment  consists  of  a  Name,  Description,  Properties,  Child  Grouping,  and  Children. 
Name  and  Description  are  mandatory  fields,  and  the  TMS  assigns  a  default  Child 
Grouping  to  each  Fragment.  A  Child  can  be  an  Element  or  another  Fragment.  Properties 
and  Children  are  optional;  a  Fragment  can  have  zero  Children  and  no  Properties.  When  a 
Fragment  has  more  than  one  Child,  some  of  those  Children  can  be  Elements  and  some 
can  be  Subfragments.  No  restriction  is  imposed  that  all  Children  must  be  either  Elements 
or  Subfragments;  Children  can  be  mixed. 

The  Eragment’s  Name  must  be  unique  across  the  TMS.  No  Element,  other  Eragment,  or 
Model  can  have  the  same  Name.  As  with  Elements,  Names  and  Descriptions  should  be 
defined  to  be  meaningful  and  to  support  reuse. 

Additional  information  about  the  Eragment  can  be  added  as  a  Eragment  Property. 
Properties,  unlike  Elements,  are  not  reusable  in  other  Eragments.  A  Eragment  Property 
corresponds  to  an  attribute  in  XME. 

Eragments  and  Sub  fragments  can  only  form  loop-free  trees  in  the  TMS.  In  other  words,  a 
Eragment  cannot  be  a  Child  of  itself,  and  A  Eragment  cannot  be  simultaneously  a 
descendant  of  another  Eragment  and  also  an  ancestor  of  that  Eragment. 

The  Child  Grouping  determines  the  order  and  number  of  occurrences  of  the  Children.  If 
there  are  no  Children,  the  Grouping  is  ignored.  Three  Child  Grouping  choices  exist: 

•  Required  to  be  in  the  sequence  shown:  each  Child  can  appear  any  number  of 
times,  but  they  must  be  in  the  order  in  which  they  appear  in  the  TMS  GUI 

•  Unordered  (but  Children  can  appear  at  most  one  time):  Any  of  the  Children  can 
be  omitted.  Each  Child  that  is  used  can  appear  at  most  once.  The  Children  that 
appear  can  be  in  any  order. 

•  Mutually  exclusive  (only  one  Child  can  appear):  Only  one  can  appear,  but  that 
type  of  Child  can  appear  any  number  of  times. 

These  Child  Grouping  options  correspond  to  the  three  varieties  of  model  groups  in  XML 
Schema  Definitions:  sequence,  conjunction  (“all”),  and  disjunction  (“choice”).  In  the 
XSD  specification,  “sequence”,  “aU”,  and  “choice”  are  the  three  kinds  of  compositors. 


3.1.1.4  Model 

An  information  model  is  a  pattern  describing  an  information  object.  The  model  defines 
the  information  object’s  parts,  properties,  and  the  relationships  between  the  different 
parts.  A  TMS  Model  consists  of  a  Name,  Description,  Properties,  Child  Grouping,  and 
Children.  Name  and  Descriptions  are  mandatory  fields,  and  the  TMS  assigns  a  default 
Child  Grouping  to  each  Model.  A  Child  can  be  an  Element  or  a  Eragment.  Properties  and 
Children  are  optional;  a  Model  can  have  zero  Children  and  no  Properties.  When  a  Model 
has  more  than  one  Child,  some  of  those  Children  can  be  Elements  and  some  can  be 
Eragments.  No  restriction  is  imposed  that  all  Children  must  be  either  Elements  or 
Eragments;  Children  can  be  mixed. 
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Other  characteristics  of  a  Model  also  parallel  the  characteristics  of  a  Fragment.  The 
Model’s  Name  must  be  unique  across  the  TMS.  No  Element,  Fragment,  or  other  Model 
can  have  the  same  Name.  As  with  Elements  and  Fragments,  Names  and  Descriptions 
should  be  defined  to  be  meaningful  and  to  support  reuse.  Additional  information  about 
the  Model  can  be  added  as  a  Model  Property.  Properties,  unlike  Elements  and  Fragments, 
are  not  reusable  in  other  Models.  The  Child  Grouping  of  a  Model  has  the  same  options 
and  meaning  as  the  Child  Grouping  for  a  Fragment. 


Figure  3-3:  A  Model  for  Cursor  On  Target 


3. 1.1.5  Schema 

An  XMF  Schema  Definition  (XSD)  can  be  generated  and  saved  from  each  Model.  The 
XSD  is  written  to  a  file  with  the  name  modelName.xsd  where  modelName  is  the  unique 
Name  of  the  Model.  Generated  schemas  can  be  accessed  via  function  calls  in  the  TMS 
Web  Service  layer. 

3.1.2  Type  Management  System  Storage 

The  TMS  stores  Elements,  Fragments,  Models,  and  Schemas  in  files.  In  addition,  log  files 
include  messages  about  modifications  made  with  the  Graphical  User  Interface  (GUI)  to 
TMS  data.  The  locations  of  these  files  are  specified  in  a  “properties”  file  deployed  with 
the  GUI.  The  TMS  Web  Services  deployment  specifies  the  directory  containing  the  XMF 
Schema  Definition  (XSD)  files  generated  by  the  TMS. 

Information  on  Elements,  Fragments,  and  Models  is  stored  in  XMF  files.  The  formats  of 
files  for  Elements,  Fragments,  and  Models  are  described  in  the  GUI  on-line  help  system. 
As  described  in  the  on-line  help,  each  XSD  file  contains  a  valid  XMF  Schema  definition. 
A  Schema  can  be  generated  for  each  Model,  and  these  Schemas  can  be  used  with  other 
information  management  applications. 
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The  simplicity  of  the  TMS  storage  system  reflects  a  design  decision  to  concentrate  on 
novel  capabilities.  The  TMS  does  not  currently  include  versioning,  but  some  protections 
are  built  into  the  GUI  for  the  user  to  recover  Elements,  Fragments,  and  Models  from 
undesired  changes.  When  modifications  are  made  using  the  GUI,  the  changes  are  made 
for  the  current  session  only  until  the  changes  are  saved.  If  changes  have  been  made  since 
the  last  save  that  the  user  would  like  to  undo,  exiting  the  GUI  without  saving  will  leave 
Elements,  Fragments,  and  Models  as  defined  in  the  last  save. 

The  Elements,  Fragments,  Models,  and  XSDs  are  stored  in  specific  directories  as 
identified  in  the  properties  file  deployed  with  the  GUI.  All  Elements  are  stored  in  one 
file.  Each  Fragment,  Model,  and  XSD  is  stored  in  a  separate  named  file.  Therefore,  one 
can  make  a  backup  copy  of  the  TMS  data  before  saving  changes.  Using  the  file  system  to 
backup  and  restore  TMS  files  is  not  without  risk.  If  a  restored  file  is  out  of  sync  with 
other  files,  the  item  will  not  be  loaded  when  the  TMS  GUI  is  next  launched.  For  example, 
suppose  some  Elements  are  deleted  and  a  Fragment  is  changed  in  a  TMS  GUI  session  to 
no  longer  refer  to  the  deleted  Elements.  If  a  copy  of  the  Fragment  file  is  restored  to  the 
state  prior  to  the  change,  an  inconsistency  will  arise.  Since  the  Elements  file  was  not 
saved  and  restored  with  the  Fragment,  Elements  in  the  restored  Fragment  no  longer  exist, 
and,  therefore  the  Fragment  cannot  be  loaded. 

These  sort  of  inconsistencies  cannot  arise  with  XSDs.  XSD  files  are  complete,  valid, 
well-formed  XMF  schemas.  Before  generating  and  saving  an  XSD  file  for  a  modified 
Model,  you  may  want  to  consider  renaming  the  last  previously-generated  XSD  file  for 
that  Model.  When  the  user  employs  the  TMS  GUI  to  generate  and  save  an  XSD  file  for  a 
Model,  the  GUI  checks  to  see  if  an  XSD  file  already  exists  for  that  Model.  If  an  XSD  file 
exists,  a  message  is  displayed  asking  the  user  if  the  existing  XSD  fide  should  be  copied 
over.  The  XSD  file  can  be  renamed,  by  using  the  file  system  outside  the  TMS  GUI,  at 
this  point. 


3.1.3  Graphical  User  Interface  to  Type  Management  System 

The  TMS  includes  a  Graphical  User  Interface  (GUI).  The  GUI  provides  capabilities  to 
support  a  COI  analyst  in  defining  a  COI  vocabulary,  in  combining  Elements  of  that 
vocabulary,  and  ultimately  in  generating  Schemas  describing  information  objects  needed 
to  support  information  management  within  and  between  COIs. 

The  TMS  GUI  is  an  Eclipse  plugin  and  was  developed  under  the  Eclipse  Integrated 
Development  Environment  (IDE).  According  to  their  website  http://www.eclipse.org, 

“Eclipse  is  an  open  source  community  whose  projects  are  focused  on 
providing  an  extensible  development  platform  and  application  frameworks 
for  building  software.” 

One  can  purchase  various  books  (for  example,  Burnette  (2005)  or  Gallardo  et  al.  (2003)) 
describing  how  to  use  Eclipse  to  develop  software. 
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3.1.3.1  GUI  Software 

The  TMS  GUI  software  is  distributed  under  this  project  in  two  zip  files.  One  contains 
source  and  development  files.  The  other  contains  the  binaries  that  are  deployed  as  an 
Eclipse  plugin.  The  software  and  development  fdes  consist  of: 

•  Various  settings  and  configuration  files  that  organize  the  software  as  an  Eclipse 
project 

•  bin:  folder  of  compiled  Java  classes  for  the  TMS  GUI 

•  doc:  folder  containing  Javadoc  files  for  the  TMS  GUI 

•  html:  folder  containing  html  files  to  incorporate  in  Eclipse  help  for  the  TMS  GUI 

•  icons:  folder  containing  an  icon  for  the  TMS  GUI 

•  META-INF:  folder  containing  a  manifest  file 

•  src:  Java  source  for  the  TMS  GUI 


The  source  code  is  organized  as  one  Java  package,  consisting  of  the  Java  classes  shown 
in  Table  3-1 .  The  TMS  GUI  is  compiled,  and  the  ICED  jar  file  is  created,  from  within 
Eclipse. 


Table  3-1:  Java  Source  ] 

For  the  TMS  GUI 

Pkg. 

Name 

Type 

Notes 

iced 

AddT  oF  ragmentDialog 

class 

extends 

org.eclipse.jface. dialogs. Dialog; 

Attribute 

class 

AttributeDialog 

class 

extends  org.eclipse.jface. dialogs.Dialog 

ChildElement 

class 

ChildElementDialog 

class 

extends  org.eclipse.jface. dialogs.Dialog 

ChildFragment 

class 

ChildFragmentDialog 

class 

extends  org.eclipse.jface. dialogs.Dialog 

Constants 

class 

Element 

class 

implements  java.lang. Comparable 

ElementContentProvider 

class 

implements  org.eclipse.jface. viewers. 

IStructuredContentProvider 

extends 

org .  xml .  sax  .helpers .  DefaultHandler 

ElementDialog 

class 

extends  org.eclipse.jface. dialogs.Dialog 

Fragment 

class 

FragmentContentProvider 

class 

implements  org.eclipse.jface. viewers. 

IT  reeContentProvider 

FragmentDialog 

class 

extends  org.eclipse.jface. dialogs.Dialog 

FragmentXMEParser 

class 

extends 

org .  xml .  sax .  helpers  .DefaultHandler 

ICEDPlugin 

class 

extends  org.eclipse.ui.plugin. 
AbstractUIPlugin 

ICEDView 

class 

extends  org. eclipse .ui. part. ViewP art 

String  Array  T  ransfer 

class 

extends  org. eclipse. swt.dnd. 
ByteArrayTransfer 
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3. 1.3.2  GUI  Deployment 

The  GUI  to  IMS  is  deployed  as  an  Eelipse  plug-in.  ITT  has  tested  it  under  Eelipse 
versions  3.1.0  and  3.2  on  a  Windows  platform.  It  has  also  been  run  under  Eelipse  version 

3.2  on  under  Mac  OS  X,  version  10.4.5,  although  these  instructions  do  not  quite  apply  to 
a  Macintosh  platform.  To  install  the  GUI,  move  the  iced  l.O.O.jar  file  and  the  iced  folder 
to  your  eclipse\plugins  directory.  The  deployment  consists  of  the  following  files: 

•  eclipse\plugins\iced_l  .O.O.jar 

•  eclipse\plugings\iced\tms  .properties 

•  eclipse\plugings\iced\elements\elements.xml 

•  eclipse\plugings\iced\fragments\README.txt 

•  eclipse\plugings\iced\models\README.txt 

One  can  delete  the  files  named  “README.txt”.  These  files  are  placeholders  created  to 
ensure  that  the  directories  in  which  they  reside  are  carried  along  in  the  deployment.  The 
GUI  is  deployed  with  a  default  “wildcard”  Element  and  no  Eragments,  Models,  or 
Schemas.  To  deploy  example  Elements,  Eragments,  and  Models,  see  the  scenario  and 
demonstration  described  in  Section  3.3.  The  user  can  redefine  the  location  in  which  the 
GUI  stores  TMS  data  by  modifying  the  tms  .properties  file  (Eigure  3-4). 


//  Indicates  a  comment  line 

//  The  directories  are  relative  to  the  directory  from  which  Eclipse  is  running,  unless 
//  the  complete  path  is  included 

element .  directory=plugins/ iced/  elements/ 
element .  filename=elements .  xml 
fragment .  directory=plugins/ iced/  fragments/ 
model. directory=plugins/iced/models/ 
xsd.directory=plugins/iced/XSDs/ 
log.directory=plugins/iced/logs/ 

Figure  3-4:  tms.properties  File  Specifies  TMS  Storage  Locations 


3. 1.3.3  GUI  Execution 

The  GUI  to  the  TMS  is  launched  from  within  the  Eclipse  SDK.  Eclipse  asks  the  user  to 
specify  a  workspace  when  Eclipse  is  being  started.  Choose  any  workspace  you  like  here; 
this  choice  is  irrelevant  to  the  TMS  GUI  plugin.  Eclipse  presents  a  series  of  pull-down 
menus  (Eile,  Edit,  Navigate,  Search,  Project,  Run,  Window,  Help)  at  the  top  of  the 
Eclipse  window.  Choose  the  Window  menu,  the  “Show  View”  option  on  the  pull  down 
menu  that  appears,  and  then  “Other”  on  the  final  submenu.  A  pop-up  window  will  then 
appear,  from  which  the  user  should  choose  “COI  TMS”  under  the  “COI  TMS”  folder. 
The  user  may  want  to  maximize  the  COI  TMS  view.  Eigure  3-5  illustrates  the  results  of 
these  steps  launching  the  TMS  GUI. 
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BBS 


^Java  -  Eclipse  SDK 


File  Edit  Navigate  Search  Project  Run  Window  Help 


Figure  3-5:  ICED  View  Launched  As  An  Eclipse  Plugin 


Once  the  TMS  GUI  has  been  launehed,  the  user  can  create,  modify,  and  save  Elements, 
Fragments,  and  Models,  thereby  defining  a  COI  vocabulary.  From  Models,  the  user  ean 
generate  and  save  XSD  files  for  describing  COI  information  objects.  The  TMS  GUI 
ineludes  an  extensive  on-line  help  system  deseribing  these  operations.  To  launch  TMS 
GUI  help,  ehoose  the  Eelipse  Help  pull  down  menu  and  the  “Help  Contents”  option  on 
that  menu.  Figure  3-6  illustrates  Eelipse  help,  with  the  TMS  help  expanded  on  the  left 
panel. 


3.1.4  Web  Services  Interface  to  Type  Management  System 

The  TMS  ineludes  a  Web  Serviees  interface.  The  TMS  Web  Serviees  perform  simple 
proeesses.  These  Web  Serviees  support  an  interaction  between  an  open  standard  input 
and  the  wide  ranging  funetionality  in  the  TMS.  The  open  standard  input  is  a  Simple 
Objeet  Access  Protoeol  (SOAP)  message  delivered  over  TCP/IP.  The  Web  Serviees  foeus 
on  the  retrieval  and  searehing  of  Schemas  generated  by  the  TMS.  The  TMS  Web 
Services  eonsist  of: 


•  getSehema 

•  getSchemaFist 

•  getSehemaFistfromPartialName 
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Figure  3-6:  TMS  Help  Accessible  Through  GUI 

The  getSchema  Web  Service  contains  only  one  parameter,  the  name  of  the  Schema  to  be 
obtained.  The  name  (for  example,  Genes. xsd)  references  the  Schema  on  the  server  side. 
This  Web  Service  returns  the  Schema  to  the  Web  Service  Client. 

The  getSchemaList  requires  no  parameters  and  simply  returns  a  list  of  all  of  the  Schemas 
available  for  searching  or  retrieval. 

The  getSchemaListfromPartialName  Web  Service  uses  only  a  single  string  parameter, 
representing  a  partial  match  of  Schemas  to  for  which  to  search.  For  example,  the  string 
“GE”  or  “ge”  returns  all  Schemas  with  names  containing  textual  subsets  which  match. 
This  Web  Service  treats  its  parameter  as  case  insensitive.  The  string  “GE”  could  return 
Schemas  named  “Genes. xsd”  and  “Page. xsd”.  A  Web  Service  client  can  use  each  Schema 
name  returned  from  getSchemaEistfromPartialName  as  the  parameter  to  the  getSchema 
Web  Service. 


3.1.4.1  TMS  Web  Service  Software 

The  software  implementing  the  TMS  Web  Services  consists  of  two  parts:  software  to 
install  on  the  Web  Services  server  and  Web  Services  client  software.  The  TMS  server 
must  have  installed  Apache  Tomcat  5.x  (http://tomcat.apache.org/),  an  open  source 
application  server.  Both  the  server  and  the  client  must  have  Java  1.5  installed.  Various 
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open  source  libraries  are  automatically  installed  as  part  of  the  deployment  process.  Look 
in  TMS/WEB-INF/lib  after  the  server-side  Web  Services  is  deployed,  or  in 
TMSClient.jar  in  the  client  deployment  to  see  these  library  packages. 

The  TMS  Web  Services  software  delivered  under  this  project  consist  of  three  archives: 

•  TMS-WS.zip  -  Files  to  deploy  under  Tomcat  on  the  TMS  Web  Services  server 

•  Type  Management  System.zip  -  TMS  Web  Services  source  code  and  related 
development  fdes 

•  TMSClient.jar  -  Default  TMS  Web  Services  client. 

The  source  code  for  the  TMS  Web  Services  is  organized  into  two  packages  (Table  3-2). 
The  Java  interface  and  classes  in  the  package  com.itt.tms.ws,  along  with  an  XML  file, 
WSDL  file,  jar  files,  etc.,  provide  TMS  Web  Server  capabilities  to  be  deployed  on  a 
server.  The  interfaces  and  classes  in  the  package  tms. client,  along  with  jar  files  for  certain 
open  source  tools,  provide  a  default  TMS  Web  Services  client.  The  TMS  Web  Services 
development  files  include  an  Ant  script.  This  Ant  script  automatically  builds  and  deploys 
the  TMS  Web  Services.  The  script  depends  on  application  settings  (JAVA  HOME, 
CATAFINA  HOME,  etc.)  defined  at  its  initialization. 


Table : 

1-2:  Organization  Of  Java  Source  Code  In  TMS  Web  Services 

Package 

Name 

Type 

Notes 

com.itt.tms.ws 

ISchemaService 

interface 

extends  java.rmi.Remote 

S  chemaN  otF  oundException 

class 

extends  java.lang.Exception 

SchemaService 

class 

implements  ISchemaService, 
j  avax.xml.rpc .  server .  serviceEifecycle 

tms. client 

ISchemaService 

interface 

extends  java.rmi.Remote 

ISchemaServicePortSoap\ 

BindingStub 

class 

extends  org. apache. axis. client.Stub, 
implements  ISchemaService 

S  chemaN  otF  oundException 

class 

extends  org . apache . axis . AxisF ault, 
implements  java.io.  Serializable 

SchemaService 

interface 

extends  javax. xml. rpc. Service 

S  chemaS  ervic  eClient 

class 

extends  javax. swing.  JFrame 

SchemaServiceEocator 

class 

extends 

org .  apache .  axis .  client .  S  ervic  e, 
implements  SchemaService 

3. 1.4.2  TMS  Web  Services  Server-Side  Deployment  and  Execution 

The  TMS  Web  Services  are  deployed  on  the  server  by  extracting  the  files  in  TMS- 
WS.zip  file.  The  files  should  be  extracted  into  a  folder,  TMS,  created  in  the  extraction. 
This  file  should  be  placed  in  the  webapps  directory  of  the  server’s  Tomcat  application. 
Tomcat  must  then  be  restarted,  after  which  the  Web  Services  will  be  deployed  at  the  URL 
of  the  server:  http://localhost:8080/TMS/services/SchemaService.  (The  port  may  differ, 
depending  on  the  installation  settings  of  Tomcat,  but  port  8080  is  prevalent.)  The  files 
deployed  for  the  TMS  Web  Services  consist  of: 
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•  apache-tomcat-5.5. 12\webapps\TMS\index.html 

•  apache-tomcat-5.5. 12\webapps\TMS\META-INF\MANIFEST.MF 

•  apache-tomcat-5 .5.1 2\webapps\TMS\WEB-INF\classes\com\itt\tms\ws\*  .class 
(three  files) 

•  apache-tomcat-5.5. 12\webapps\TMS\WEB-INF\classes\log4j. properties 

•  apache-tomcat-5.5. 12\webapps\TMS\WEB-INF\classes\SchemaService.wsdl 

•  apache-tomcat-5 .5.1 2\webapps\TMS\WEB-INF\lib\*  .j ar  ( 1 0  files) 

•  apache-tomcat-5.5. 12\webapps\TMS\WEB-lNF\server.config.wsdd 

•  apache-tomcat-5.5. 12\webapps\TMS\WEB-INF\web.xml 

The  server  configuration  includes  the  definition  of  the  directory  in  which  TMS  Schemas 
are  stored.  A  context  parameter  (Figure  3-7)  is  defined  in  the  web. xml  file  deployed  as 
described  above.  To  configure  the  TMS  Web  Services  for  your  server,  change  the  value 
of  the  context  parameter  to  match  the  location  of  the  Schemas  in  your  installation  of  the 
TMS. 


2  <context-param> 

<param-name>XSDPath</param-name> 

<param-value>C:/XSDs/</param-value> 

</co  n text- pa  ra  m  > 

Figure  3-7:  Default  Definition  of  Location  of  TMS  Schemas 

One  can  check  that  the  TMS  Web  Services  are  available,  once  they  have  been  deployed 
and  Tomcat  has  been  restarted.  Point  your  Web  browser  to  the  following  URL: 
http://localhost:8080/TMS/services/SchemaService?WSDL.  If  the  TMS  Web  Services 
have  been  correctly  configured,  the  server  should  return  the  Web  Services  Definition 
Language  (WSDL)  for  the  TMS  Web  Services,  as  shown  in  Figure  3-8. 


3. 1.4.3  Client  Deployment 

The  TMS  Web  Services  software  includes  a  default  Web  Services  client.  This  default 
client,  excluding  the  Web  Services  client  GUI,  was  generated  using  WSDL-to-Java,  an 
Apache  Axis  utility.  Similar  tools  for  generating  Web  Services  clients  are  available  for 
C++  and  other  languages. 

To  deploy  the  default  client,  copy  the  “TMSClient.jar”  file  into  a  newly  created  folder 
named,  say,  TMSClient.  This  jar  file  is  all  that  needs  to  be  present  for  TMS  Web  Services 
client. 


3. 1.4.4  Client  Execution 

From  a  MS-DOS  window,  change  the  working  directory  to  be  TMSClient.  Your  Java 
CLASSPATH  variable  should  include  the  current  directory.  Execute  the  command  “java 
-jar  TMSClient.jar”.  A  window  should  open,  as  shown  in  Figure  3-9.  Each  one  of  the 


21 


three  Web  Services  can  be  invoked  by  pushing  the  corresponding  button  at  the  bottom  of 
the  window.  The  first  two  Web  Services,  to  search  for  Schemas  and  to  get  a  specified 
Schema,  each  require  a  text  string  as  an  argument.  That  argument  should  be  entered  in 
the  box  at  the  top  of  the  window. 


|'3  http://localhost:8080/TMS/services/SchemaService?WSDL  -  Microsoft  Internet  Explorer 

RIe  yit  WevM  Favorites  Tools  Help 

©Back  -  Q  3  @  fll  P^ea,*  Favorites  .0  ^  0  23,  •'i4 

Address  1^  http://localhost:8080/TM5yservices/SchemaService?WSDL 

V- 1  m  Go  Links  ’ 

<?xml  versions" l.D"  encoding="UTF-8'‘  ?> 

-  <wsdl; definitions  targetNamespace="com.ltt.tms.ws.ISchemaServlce"  xmlns;apachesoap="http://xml. apache.org/xml-soap" 
xmlns;impl="com.itt.tms.vMS.ISchemaServlce''  xmlns:intf="com.ltt.tms.ws.ISchemaService" 

xmlns;wsdl="http://schemas. xmlsoap.org/wsdl/"  xmlns;wsdlsoap="http://schemas. xmlsoap.org/wsdl/soap/" 
xmlns;xsd="http:// www.w3.org/2001/XMLSchema"> 

-  <!” 

WSDL  created  by  Apache  Axis  version:  1.3 
Built  on  Oct  05,  2005  (05:23:37  EDT) 

"> 

-  <wsdl:types> 

-  <schema  elementFormDefault="quallfied"  targetNamespace=‘'com.itt.tms.ws.ISchemaService" 
xmlns=''http://www.w3.org/2001/XMLSchema"> 

-  <element  name="getSchemaLlst"> 

<complexType  /> 

</element> 

-  <element  name="getSchemaLlstResponse"> 

-  <complexType> 

-  <sequence> 

<element  maxOccurs="unbounded"  name="getSchemaListReturn"  type="xsd:string"  /> 

</sequence> 

</complexType> 

</element> 

-  <complexType  name="SchemaNotFoundExceptlon"> 

-  <sequence> 

<element  name="errorMessage"  nillable="true"  type="xsd:strlng"  /> 

</sequence> 

</complexType> 

<element  name="fault"  type="(mpl:SchemaNotFoundException"  /> 

-  <element  name="getSchemaLlstFromPartialName"> 

-  <complexType> 

-  <sequenc8> 

<element  name="partlalMame"  typ8="xsd:strlng"  /> 

</sequence> 

</complexType> 

<-  /p|piTiont-» 

Done  Local  intranet 

Figure  3-8:  The  TMS  WSDL  Returned  From  Server 


3.2  Schema  Definition  and  Maintenance  Process 

This  section  describes  schema  processes  supported  by  schema  definition  tools.  The  TMS 
is  a  prototype  designed  to  assist  in  understanding  schema  definition  and  maintenance 
processes  and  the  requirements  of  tools  providing  automated  support  to  such  processes. 
The  TMS  provides  benefits  to  COI  information  engineers  and  to  their  managers 
following  these  processes. 

The  TMS  is  designed  to  support  configuring  information  management  tools,  such  as 
IMCS  or  NCES,  in  a  COI.  The  ICED  project  is  premised  on  the  assumption  that  such 
tools  are  configured  by  means  of  XSD  files,  and  that  this  configuration  activity  is  one 
necessary  task  in  setting  up  a  COI.  A  COI  information  engineer  is  defined,  in  the  context 
of  the  ICED  project,  as  a  person  who  is  tasked  with  configuring,  or  maintaining  the 
configuration  of,  information  management  tools. 
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Figure  3-9:  The  TMS  Web  Services  Client 

The  TMS  supports  the  COI  information  engineer,  that  is,  a  typical  TMS  user,  by  allowing 
him  to  concentrate  on  the  domain  or  application  area  of  concern  to  the  COI.  The  TMS 
user  is  assumed  to  have: 

•  Domain  knowledge  (for  example,  of  tactical  military  applications) 

•  Some  exposure  to  introductory  computer  science. 

The  TMS  user  is  expected  to  know  that  variables  have  types  and  that  data  types  can  be 
defined  in  hierarchies,  where  fields  in  one  data  type  are  themselves  of  some  defined  type. 
This  knowledge  is  helpful  in  conceptually  understanding  what  one  is  doing  in  interactions 
with  the  TMS  GUI.  On  the  other  hand,  the  TMS  user  does  not  necessarily  need  to  know 
ontological  engineering,  XML,  or  XSD.  Advanced  users  who  may  know  XML  and  XSD 
will  still  find  the  TMS  useful  in  that  it  allows  them  to  quickly  generate  valid  XSD  files 
and  to  visualize  their  schemas  more  easily  than  is  possible  in  examining  a  raw  XSD  file. 

The  manager  of  a  COI  information  engineer  benefits  from  the  TMS  in  that  the  TMS 
allows  him  to  select  information  engineers  from  a  wider  range  of  candidates.  He  can  now 
choose  information  engineers  whose  area  of  expertise  is  more  in  the  COI  application 
areas,  instead  of  in  XML  and  XSD.  The  TMS  allows  him  to  more  quickly  have  such 
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candidates  applying  their  skills  to  COI  issues,  without  first  having  gone  through  training 
in  XSD  development.  The  TMS  allows  users  to  build  up  and  share  libraries  of  Elements 
and  Fragments.  The  contents  of  these  libraries  can  be  reused  in  different  Models,  and  the 
TMS  GUI  allows  both  information  engineers  and  others  to  quiekly  and  easily  understand 
the  strueture  of  domain  data.  The  manager  of  information  engineers  benefits  from  these 
eapabilities  in  that  the  TMS  allows  the  sharing  of  work  produets  more  easily  among  those 
reporting  to  him  and  with  other  groups.  Given  the  TMS  Web  Services,  some  of  this 
sharing  can  even  be  done  in  maehine-to-machine  information  exchange. 

The  TMS  supports  proeesses  for  developing  schemas.  Figure  3-10,  based  on  a  figure  in  a 
textbook  on  ontologieal  engineering  (Gomez-Perez  et  al  2004),  illustrates  sehema 
development  processes  and  how  they  fit  into  a  larger  set  of  proeesses.  The  development 
of  a  schema  is  intended  to  produee  an  XSD  file,  in  the  case  of  the  TMS,  for  use  in  some 
later  proeess.  The  TMS  Web  Services  supports  feeding  the  output  of  schema 
development  proeesses  into  use  processes.  The  TMS  can  support  the  development  of  a 
schema  in  iterative  processes,  in  which  the  schema  beeomes  inereasingly  detailed  in  later 
iterations.  Figure  3-10  suggests  four  such  iterations.  During  maintenance  proeesses,  the 
TMS  user  can  use  the  TMS  to  eorrect  mistakes  diseovered  in  schemas,  ehange  schemas 
to  support  new  capabilities,  or  to  adapt  schemas  to  changes  in  the  environment  in  whieh 
schemas  are  used. 
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Development  Oriented 

Support 

^  TMS-Supported\ 
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1  Implementation  / 

V  Maintenance  J 

Configuration 
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Alignment 

Figure  3-10:  Schema  Processes 


As  information  management  tools  become  more  ubiquitous,  the  management  of  schema 
development  will  beeome  more  important.  Management  eonduets  it  owns  proeesses. 
These  processes  include  seheduling  and  planning  schema  development  processes, 
controlling  schema  development  processes  in  ensuring  that  they  are  preformed  on 
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schedule  and  within  budget,  and  assuring  that  sehema  development  proeesses  following 
defined  proeesses.  Sehema  development  processes  also  require  various  supporting 
processes.  One  supporting  proeess  would  assess  whether  a  developed  sehema  meets  its 
requirements.  Sehemas  must  be  doeumented.  Sehemas,  Models,  Fragments,  and  Elements 
ereated  with  the  TMS  might  exist  in  different  versions,  and  a  eonfiguration  management 
process  would  help  in  keeping  traek  of  different  versions.  To  support  reuse.  Schemas, 
Models,  Fragments,  and  Elements  might  need  to  be  aligned  with  standards  and  style 
guides  required  before  entry  into  reusable  libraries. 

The  TMS  supports  implementing  eaeh  iterative  development  proeess  as  either  a  top-down 
or  a  bottom-up  process  (Figure  3-11).  The  TMS  allows  one  to  save  Models  and 
Fragments  with  no  ehildren  and  properties.  This  eapability  is  needed  to  support  the  top- 
down  development  proeess  shown.  Fikewise  the  TMS  allows  the  user  to  save  Elements 
that  are  not  ehildren  of  any  Fragments  that  have  yet  been  defined  and  Fragments  that  are 
not  yet  children  of  any  defined  Models.  These  are  neeessary  eapabilities  for  a  bottom-up 
development  proeess.  In  either  proeess,  the  TMS  allows  the  user  to  reuse  and  modify 
existing  Models,  Fragments,  and  Elements.  In  this  way,  the  TMS  supports  an  exploratory 
style  of  development. 
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Figure  3-11:  Top-Down  and  Bottom-Up  Schema  Development  Processes 

The  TMS  is  a  proof  of  concept  showing  that  appropriate  automated  support  can  ease  the 
cognitive  burden  in  configuring  information  management  tools  for  a  COL  The  TMS  does 
not  support  a  full  implementation  of  XSD  or  a  full  deseription  of  ontologies.  Some  XSD 
eapabilities  not  available  in  the  XSDs  generated  by  the  current  version  of  the  TMS  may 
be  useful  or  required  for  COl  information  engineering.  The  experience  of  the  TMS 
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developers  suggests  that  if  the  IMS  were  extended  to  fully  implement  XSD  standards 
(e.g.  W3C  2004),  it  would  beeome  inereasingly  diffieult  to  eneapsulate  eomplex  syntax 
and  semantie  aspeets  of  XML  and  XSD.  For  example,  ITT,  fairly  late  in  this  effort,  added 
a  capability  to  associate  regular  expressions  with  properties  defined  for  each  Fragment  or 
Model.  Regular  expressions  are  merely  strings  in  the  TMS;  the  user  is  not  assisted 
appreciably  in  the  understanding  of  how  to  construct  a  regular  expression.  One  is  taking  a 
risk  if  one  concludes  from  this  research  that  the  full  education  requirements  of  a  COI 
information  engineer  does  not  require  XML  and  XSD  training,  since  full  tool  support  is 
not  conclusively  provided  by  the  TMS  to  give  the  engineer  all  needed  capabilities 
without  the  engineer  ever  examining  XML  and  XSD  code. 


3.3  Scenario  and  Demonstration 

The  ICED  demonstration  illustrates  schema  processes,  demonstrates  selected  TMS 
features,  and  provides  a  capability  with  which  any  TMS  user  can  demonstrate  the  TMS  to 
others.  The  demonstration  shows  the  top-down  development  of  a  Model,  the  generation 
of  a  Schema,  and  the  retrieval  of  that  Schema  by  the  TMS  Web  Services.  The  Model 
development  in  the  demonstration  reuses  an  existing  Fragment  and  illustrates  the 
development  of  new  Fragments.  The  Model  development  and  XSD  generation  illustrate 
capabilities  of  the  TMS  GUI.  The  XSD  retrieved  by  the  TMS  Web  Services  can  be  used 
to  configure  information  management  tools,  assumed  to  be  available  in  the  demonstration 
scenario  to  the  TMS  user.  This  demonstration  can  be  run,  using  the  information  in  this 
report,  without  ITT  support. 


3.3.1  Demonstration  Scenario 

The  scenario  defined  for  the  demonstration  provides  a  setting  in  which  the  TMS  user 
actions  conducted  during  the  demonstration  are  plausible.  The  scenario  presents  the 
actions  of  a  COI  information  engineer  with  domain  knowledge  of  tactical  military 
operations  that  are  planned  to  be  conducted  in  the  COL  The  scenario  illustrates  that  the 
COI  information  engineer  does  not  need  knowledge  of  XML  or  XSD  to  use  the  TMS. 

In  the  scenario,  the  COI  is  temporarily  isolated  from  NCES  and  the  DDMR.  Perhaps  the 
internal  components  of  the  COI  are  being  set  up,  while  some  issue  with  remote 
communications  is  being  investigated.  The  scenario  postulates  the  COI  information 
engineer  has  a  rich  collection  of  information  management  tools,  and  these  are  configured 
to  transmit  geographical  information,  but  in  non-Cursor  On  Target  (COT)  format.  The 
TMS  is  assumed  to  contain  a  Schema,  decomposed  for  this  geographical  information 
prior  to  the  start  of  the  demonstration.  This  Schema  (Eigure  3-12)  has  latitude  and 
longitude  specified  in  terms  of  degrees,  minutes,  and  seconds;  the  COT  schema  requires  a 
single  real  number  for  each  dimension.  The  detail  Eragment  in  this  existing  Schema  can 
be  reused  in  the  COT  Schema.  The  COT  Schema  also  requires  the  definition  of  various 
Properties  or  XML  attributes  not  in  the  existing  Schema  for  geographical  information. 

In  the  demonstration  scenario,  the  COT  information  engineer  is  tasked  with  creating  a 
COT  Schema  (Eigure  3-13).  The  COI  information  engineer  is  assumed  to  have  access  to 


26 


a  rich  set  of  information  management  tools  in  the  COT.  The  COT  Sehema  created  with 
the  TMS  can  be  used  to  configure  some  of  these  tools.  For  example,  the  COT  Schema 
can  be  used  to  specify  information  objects  to  be  transmitted  between  components  within 
the  COL  Or  the  COT  Schema,  in  combination  with  the  existing  Schema  might  be  used  to 
configure  a  fuselet  to  convert  from  information  objects  described  by  the  COT  Sehema  to 
information  objeets  described  by  the  pre-existing  Schema. 


Figure  3-12:  Initial  Model,  Fragments,  and  Element  In  Demonstration 
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Figure  3-13:  COI  Is  Configured  In  Scenario 
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3.3.2  Demonstration  Deployment 

The  TMS  demonstration  data  is  deployed  in  the  ICEDDemo.zip  file.  The  demonstration 
data  is  extraeted  into  a  folder  DemoData,  ereated  in  the  extraetion.  The  demonstration 
data  is  organized  into  two  folders; 

•  DemoData\DemoStart:  The  folders  and  files  for  configuring  the  TMS  before  the 
demonstration  begins. 

•  DemoData\DemoEnd:  The  folders  and  files  for  configuring  the  TMS  to  display 
the  full  COT  Model  during  the  demonstration. 

To  configure  TMS  to  display  the  demonstration  data  at  the  appropriate  point  in  the 
demonstration,  delete  the  files  and  folder  in  Eclipse\plugins\iced  and  copy  the  files  and 
folders  in  either  DemoStart  or  DemoEnd  to  Eclipse\plugins\iced.  Eurther  details  about 
when  to  configure  the  TMS  with  the  demonstration  data  is  provided  in  Section  3.3.3. 


3.3.3  Demonstration  Steps 

Before  beginning  the  demonstration,  the  TMS  must  be  configured  to  contain  the  initial 
data  used  in  the  demonstration.  To  begin  the  configuration,  delete  the  files  and  folder  in 
the  Eclipse\plugin\iced  directory.  Then  copy  the  file  tms.properties,  and  the  folders, 
including  their  contents,  from  DemoDataVDemoStart  to  Eclipse\plugins\iced,  to  configure 
the  TMS  as  described  in  Section  3. 1.3. 2.  Start  up  the  TMS  Web  Services  server,  as 
described  in  Section  3. 1.4. 2.  This  completes  the  demonstration  configuration. 

The  ICED  demonstration  consists  of  1 1  steps: 

1 .  Browse  initial  TMS  configuration 

2.  Create  COT  event  Model 

3.  Reuse  existing  detail  Eragment  as  event  child 

4.  Create  COT  point  Eragment 

5 .  Append  point  Eragment  to  event  children 

6.  Edit  event  to  ensure  children  are  unordered 

7.  Define  version  property  for  event  Model 

8.  Define  lat  property  for  point  Eragment 

9.  To  skip  over  defining  each  Property,  restore  complete  COT  event  Model  and 
browse  properties 

10.  Generate  XSD 

1 1 .  Demonstrate  Web  Services  Schema  browsing 


3.3.3. 1  Browse  Initial  TMS  Configuration 

Display  the  COI  TMS  configuration,  as  described  in  Section  3. 1.3. 3.  You  will  see  that  a 
single  Model,  EarthLocation,  is  defined.  Edit  EarthLocation  by  right-clicking  on  its 
name  and  selecting  “Edit”  from  the  popup  menu  that  appears.  You  can  point  out  that 
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EarthLocation  has  no  properties,  and  its  ehildren  are  unordered.  When  you  are  done 
examining  the  EarthLocation  window,  click  on  the  “Cancel”  or  “OK”  button  in  the  lower 
right.  By  clicking  on  the  “plus”  next  to  EarthLocation,  you  can  show  that  it  has  two 
children,  EarthPoint  and  detail.  Since  these  children  names  appear  in  the  Fragment 
window,  these  children  are  both  Fragments. 

Edit  EarthPoint  by  right-clicking  on  its  name  in  either  or  both  the  Model  window  and  the 
Fragment  window.  In  the  Model  window  editing,  you  can  see  that  exactly  one  EarthPoint 
Fragment  must  appear  in  the  EarthLocation  Model.  You  can  see  how  the  ranges  of  the 
properties  of  this  Fragment  are  specified,  and  how  different  types  are  appropriate  for 
different  ranges. 

Edit  the  detail  Fragment.  You  can  see  that  it  has  one  property,  wildcard,  which  cannot  be 
edited.  You  can  also  see  that  the  detail  Fragment  has  one  child,  wildcard. 

At  this  point,  you  have  examined  the  Model  initializing  the  demonstration  (Figure  3-14). 
The  user  in  the  scenario  would  like  to  reuse  the  detail  Fragment  in  the  COT  event  Model, 
needs  properties  not  in  the  initial  Model,  and  needs  to  specify  the  location  on  the  earth  in 
a  different  format  than  in  the  EarthLocation  Model.  The  remaining  demonstration  steps 
create  a  Model  in  which  these  needs  are  met. 
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Figure  3-14:  Browsing  Fragments  in  the  Earth  Location  Model 
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3.3.3.2  Create  COT  event  Model 

Click  on  the  “Create  New  Model”  button  on  the  upper  right  of  the  COI  TMS  view.  In  the 
window  that  appears  enter  “event”  as  the  name  and  “Event  Definition”  as  the  deseription. 
When  done,  eliek  on  the  “OK”  button  on  the  lower  right.  The  name  of  your  newly- 
ereated  event  Model  should  now  be  displayed  in  the  Model  window. 


3.3.3.3  Reuse  detail  Fragment  as  event  Child 


Right-cliek  on  detail  in  the  Model  window,  and  select  “Add  Fragment  to  Model”  from 
the  popup  menu  that  appears.  A  window  will  appear  in  whieh  the  two  Fragments,  detail 
and  EarthPoint  are  listed.  Cliek  on  detail  in  that  window,  and  it  will  beeome  highlighted. 


Cliek  “OK”. 


A  new  window  for  the  detail  ehild  then  appears.  Enter  0  for  the  “Minimum  Oeeurrenee” 
and  aeeept  the  default  value  of  unity  for  the  “Maximum  Oeeurrenee”  by  elieking  on  the 
“OK”  button. 


3.3.3.4  Create  COT  point  Fragment 

Cliek  on  the  “Create  New  Fragment”  button  on  the  upper  right  of  the  COI  TMS  view.  In 
the  window  that  appears  enter  “point”  as  the  name  and  “Point”  as  the  deseription.  When 
done,  eliek  on  the  “OK”  button  on  the  lower  right.  The  name  of  your  newly-ereated  point 
Fragment  should  now  be  displayed  in  the  Fragment  window. 


3.3.3.5  Append  point  Fragment  to  event  Children 

The  point  Fragment  ean  be  made  a  child  of  the  event  Model  in  the  same  way  that  the 
detail  Fragment  was,  as  deseribed  in  Section  3. 3. 3. 3.  For  variety,  you  can  demonstrate 
the  drag  and  drop  eapability  of  the  TMS  GUI.  Both  the  “Minimum  Oeeurrenee”  and  the 
“Maximum  Oeeurrenee”  of  point  should  be  the  default  value  of  unity. 


3.3.3.6  Edit  event  To  Ensure  Children  Are  Unordered 

In  an  instanee  of  the  COT  event  Sehema,  the  ehildren  Fragments  ean  appear  in  any  order. 
At  most  one  instanee  of  eaeh  ehild  ean  appear.  Displaying  the  TMS  GUI  help  eapabilities 
is  not  a  formal  step  in  the  demonstration.  This  step,  however,  might  be  a  good 
opportunity  to  bring  up  the  help  system,  following  the  guidanee  in  Seetion  3. 1.3. 3.  What 
it  means  for  a  Model’s  ehildren  to  be  unordered  is  explained  in  the  “Create  New  Model” 
explanation  under  TMS  help 

To  ensure  the  COT  event  Model’s  children  are  unordered,  edit  the  event  Model  by  right- 
elieking  on  its  name  in  the  Model  window,  and  seleet  “Edit”  from  the  popup  menu  that 
appears.  Seleet  “Unordered”  in  the  radio  button  menu  for  the  Model’s  ehildren  in  the 
window  that  appears.  Click  the  “OK”  button  when  finished.  Figure  3-15  shows  a  display 
when  browsing  the  TMS  data  at  this  point  in  the  demonstration. 
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Figure  3-15:  event  Model  has  point  and  detail  Fragments  As  Unordered  Children 


3.3.3.7  Define  version  Property  For  event  Model 

Once  again,  edit  the  event  Model.  Cliek  on  the  button  labeled  “Would  you  like  to  enter 
additional  properties  pertaining  to  this  Model?” 

Enter  “version”  for  name.  Choose  the  decimal  type  for  the  Data  Type.  Leave  pattern  and 
minimum  value  blank.  Enter  a  maximum  value  of  2,  enter  a  deseription  of  “version”,  and 
specify  that  this  property  is  required.  When  done,  click  “OK”. 


3.3.3.8  Define  lat  Property  For  point  Fragment 

Edit  the  point  Eragment  from  the  Eragment  window.  Cliek  on  the  button  labeled  “Would 
you  like  to  enter  additional  properties  pertaining  to  this  Eragment?” 

Enter  “lat”  for  name.  Choose  the  deeimal  type  for  the  Data  Type.  Leave  pattern  blank, 
enter  a  minimum  value  of  -90,  enter  a  maximum  value  of  90,  enter  a  description  of 
“Latitude  based  on  WGS-84  ellipsoid. . .”,  and  specify  that  this  property  is  required 
(Eigure  3-16).  When  done,  cliek  “OK”. 
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Figure  3-16:  Defining  a  Property  for  point  Fragment 


3.3.3.9  Restore  Complete  COT  event  Model  And  Browse  Properties 

Exit  Eclipse,  and  delete  the  files  and  folder  in  the  Eclipse\plugin\iced  directory.  Then 
copy  the  file  tms.properties,  and  the  folders,  including  their  contents,  from 
DemoData\DemoEnd  to  Eclipse\plugins\iced,  to  configure  the  IMS  as  described  in 
Section  3. 1.3. 2. 

Restart  Eclipse  and  display  the  COI  IMS  view.  You  should  browse  the  COT  event 
Model,  in  the  same  way  you  browsed  the  EarthLocation  Model  in  the  first  step  of  the 
demonstration  (Section  3.3.3. 1).  Note  that  both  the  event  Model  and  the  point  Eragment 
have  several  more  properties  defined.  (Eigure  3-17  shows  the  properties  for  the  point 
Eragment.)  This  step  of  restoring  the  TMS  database  is  merely  a  shortcut  to  defining  all  of 
these  properties. 


3.3.3.10  Generate  XSD 

Right-click  on  the  name  of  the  event  Model  in  the  Model  window,  and  select  “Generate 
and  Save  XSD”  from  the  popup  menu  that  appears.  You  can  browse  the  XSD  file  created 
by  the  TMS  by  clicking  on  “View  XSD”  on  the  upper  right  of  the  COI  TMS  view.  The 


32 


TMS  GUI  allows  a  long  XSD  file  to  be  easily  browsed  and  displayed  in  a  eompaet  form 
to  the  user. 


Figure  3-17:  Properties  For  point  Fragment 


3.3.3.11  Demonstrate  Web  Services  Schema  Browsing 

Invoke  the  TMS  Web  Services  client,  as  described  in  Section  3. 1.4.4.  You  should,  at 
least,  display  the  event  XSD  created  from  the  TMS  GUI  (Figure  3-18).  The  TMS  Web 
Services  provides  a  capability  for  other  systems  to  automatically  extract  XSD  files  from 
the  TMS.  As  such,  human  readability  of  the  XSD  returned  by  the  TMS  Web  Services  was 
not  emphasized  during  TMS  development. 
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Search  For:  event.xsd 


Search  FtesuKs 


|«?xml  version-'l  .0"  encoding=”UTF-8"?><xs:schema 

xmlns:xs="http:/Awww.w3.org/2001/XMLSchema"  elementFormDefault="unqualified''> 
|<xs:element  name=''evenf'>  <xs:annotation>  <xs:documentation> 


</Xs:documentation> 


</xs:annotation> 

<xs:all> 


levent:  Event  Definition 

<xs:complexType> 

|«xs:element  name-'detail"  type- 'detail''  minOccurs="0"  maxOccurs="1"> 

|<xs:element  name="poinr  type="poinn>  <fxs:all> 

l«xs:attnbute  name-'version"  use="required">  «xs;annotation> 
l<xs:documentation>  version 

|</xs:documentation> <fxs:annotation> <xs:simpleType> 


5 .0_04\bin ; . 
NDOUSSSysten^ 
•an  FilesNQuic 


Search  for  Schemas 

Get  Schema 

Ftetrieve  All  Schemas 

Exit 

INFO:  Starting  Servlet  Engine:  flpache  Tomcat/S .5 .12 
Sep  11,  2006  2:09:15  PM  org. apache .Catalina. core .StandardHost  start 
INFO:  XML  validation  disabled 

Sep  11,  2006  2:09:20  PM  org. apache .coyote .httpll .HttpllBaseProtocol  start 
INFO:  Starting  Coyote  HTTP/l.l  on  http-8080 

Sep  11,  2006  2:09:20  PM  org. apache  .jk.coininon  .ChannelSocket  init 
INFO:  JK:  ajpl3  listening  on  /0. 0.0. 0:8009 
Sep  11,  2006  2:09:21  PM  org. apache .Jk. server. JkMain  start 
INFO:  Jk  running  ID=0  tiine=0/32  config=null 

Sep  11,  2006  2:09:21  PM  org. apache .catallna.storeconf ig.StoreLoader  load 

tINFO:  Find  registry  server-registry .xml  at  classpath  resource 
Sep  11,  2006  2:09:21  PM  org. apache .catalina. startup. Catalina  start 
INFO:  Server  startup  in  6031  ns 


;:S>cd  TMSClient 

;:\TMSClient>jaua  -jar  TMSClient .jar 


Qi 


Figure  3-18:  XSD  for  COT  Returned  By  TMS  Web  Services  Client 
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4.0  Conclusions 

Under  the  ICED  project,  ITT  developed  a  proof-of-concept  software  tool,  the  Type 
Management  System  (TMS),  to  assist  in  the  definition  of  a  COI  vocabulary  and  the 
construction  and  management  of  schemas.  A  goal  of  the  project  was  to  demonstrate  the 
possibility  of  a  functional  tool  for  COI  information  engineers  that  would  not  require 
strong  XML  and  XSD  knowledge.  While  this  goal  can  be  attained  if  the  tool  functionality 
is  limited,  ITT  found  that  as  capabilities  were  added  to  the  tool,  the  user  would  become 
increasingly  likely  to  require  specific  XML,  XSD,  and  computer  science  knowledge.  The 
XSD  specification  is  such  that  abstracting  all  computer  science  complexities  from  the 
user  seems  to  be  impossible.  In  addition  to  achieving  certain  research  results,  ITT 
identified  some  directions  for  future  research  during  the  course  of  this  development. 


4.1  Achievements 

The  achievements  of  the  ICED  project  are  easily  summarized: 

•  Produced  a  prototype  TMS  to  support  a  COI  information  engineer  in  defining 
XSDs  for  use  in  COI  information  management 

•  Defined  an  iterative  and  hierarchical  schema  development  process  supported  by 
the  TMS 

•  Defined  a  scenario  and  produced  a  demonstration  of  the  TMS  operating  under  that 
scenario 

•  Identified  directions  for  future  research  for  the  development  of  the  TMS  and  the 
schema  processes  supported  by  the  TMS 

This  research  promises  to  benefit  COI  information  engineers  and  their  managers.  After 
the  technology  described  in  this  report  is  matured  and  transitioned,  managers  will  not 
require  engineers  trained  in  XML  and  XSD.  Information  engineers  can  concentrate  on 
issues  in  their  application  areas  and  data  domains,  rather  than  XML  and  XSD  syntax. 
Managers  and  engineers  can  more  easily  visualize  and  understand  their  domain  data. 
Engineers  can  quickly  create  and  modify  descriptions  of  their  domain  data  using  easy  to 
understand  schema  modeling  concepts.  Linally,  the  TMS  Web  Services  illustrates 
capabilities  for  machine-to-machine  access  to  schema  modeling  information,  with  no 
requirement  for  human  examination  of  XSDs. 


4.2  Directions  for  Future  Research 

The  TMS  and  its  demonstration  show  that  COI  information  engineers  configuring 
information  management  tools  can  benefit  from  automated  software  tool  support.  The 
prototype  support  provided  by  the  TMS  can  be  improved  with  research  in  five  areas: 

•  Expansion  of  TMS  support  to  additional  features  of  the  XSD  language 

•  Additional  capabilities  of  the  TMS  GUI 
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•  Additional  capabilities  of  the  TMS  Web  Serviees 

•  Additional  eapabilities  of  the  TMS 

•  Expansion  of  TMS  usefulness  by  global  improvements,  ineluding  in  the  proeesses 
supported  by  the  TMS  and  in  the  environment  whieh  it  operates. 


4.2.1  Expansion  of  the  Subset  of  XSD  Features  Implemented  in 
the  TMS 

Currently,  the  TMS  supports  the  generation  of  only  a  subset  of  the  XSD  language.  A 
researeh  question  is  whether  software  tool  support  would  still  allow  a  COI  information 
engineer  to  concentrate  on  application  issues,  without  worrying  about  XML  and  XSD 
details,  if  more  features  of  the  XSD  language  were  implemented  in  the  TMS.  The 
implementation  of  the  eomplete  set  of  XSD  data  types  in  the  TMS  is  one  additional  XSD 
language  eapability  that  could  be  added.  The  TMS  currently  provides  some  simple  type 
constraints  on  properties  for  Fragments  and  Models;  future  researeh  could  add  a 
capability  to  specify  simple  type  eonstraints  for  Elements.  In  any  case,  simple  type 
eonstraints  eould  be  expanded  to  inelude  all  options  available  for  XDSs,  including  global 
simple  type  eonstraints.  The  TMS  does  not  eurrently  support  all  XSD  elements  and 
attributes,  and  additional  researeh  might  explore  expanding  support  here  too. 


4.2.2  Additional  TMS  GUI  Capabilities 

Additional  eapabilities  can  be  added  to  the  TMS  GUI.  Undo  funetionality  would  be  a 
powerful  addition.  One  might  add  drag  and  drop  eapability  to  allow  the  user  to  order  the 
display  of  Elements,  Fragments,  and  Models  at  all  levels. 


4.2.3  Additional  TMS  Web  Services  Capabilities 

TMS  Web  Serviees  currently  allow  to  Web  Services  to  seareh  and  list  the  names  of  XSD 
files  and  to  retrieve  the  eontents  of  a  named  XSD  file.  Additional  Web  Services  can 
expand  the  capabilities  of  machine-to-machine  interaetions  with  the  TMS.  Web  Services 
could  be  added  to  create  Elements,  Fragments,  and  Models.  One  might  also  add  Web 
Services  to  edit  existing  Elements,  Fragments,  and  Models.  Furthermore,  network 
security  can  be  added  by  eertificate  and  client  authentieation,  as  in,  for  example,  NCES 
Seeurity  Services.  Along  with  sueh  network  security  should  come  eapabilities 
distinguishing  what  TMS  data  different  clients  have  aeeess  to. 


4.2.4  Additional  TMS  Capabilities 

The  TMS  data  storage  eapabilities  were  not  emphasized  during  the  ICED  projeet.  Future 
researeh  could  add  a  number  of  eapabilities  here.  For  example,  the  TMS  could  be 
modified  to  store  data,  sueh  as  Elements,  Fragments,  and  Models,  in  a  relational  database. 
Access  to  TMS  data  can  be  eontrolled  with  future  ownership  and  permission 
functionality.  Being  able  to  manage  multiple  versions  of  Elements,  Fragments,  Models, 
and  Sehemas  would  be  another  capability. 
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Access  to  Schemas,  Models,  Fragments,  and  Elements  ereated  and  maintained  by  the 
TMS  could  be  provided  to  other  information  management  tools,  outside  of  a  Web 
Services  context.  Future  researeh  eould  investigate  the  ereation  of  a  TMS  Application 
Program  Interface  (API)  to  provide  capabilities  for  integrating  the  TMS  with  other 
software  tools  and  systems. 

Capabilities  to  load  TMS  data  from  other  applications  imply  a  need  for  further 
functionality.  In  particular,  validity  checks  should  be  researched  to  ensure  that  TMS  data 
is  stored  and  loaded  in  a  consistent  state.  Furthermore,  a  capability  to  load  XSDs  not 
generated  from  the  TMS  into  the  TMS  eould  be  useful,  espeeially  if  Models,  Fragments, 
and  Elements  can  automatically  be  generated  from  such  loaded  XSDs. 


4.2.5  Expansion  of  Usefulness 

The  TMS  currently  supports  the  development  of  XSD  but  does  not  capture  ontology 
information,  as  coded,  for  example,  in  OWE.  Future  research  could  explore  capabilities 
to  support  ontologieal  development  and  maintenance  proeesses. 

The  TMS  is  intended  to  operate  in  an  environment  with  rieh  information  management 
tools,  but  the  ICED  projeet  did  not  investigate  interaetions  with  tools  and  services,  either 
existing  or  under  development.  Future  research  might  investigate,  for  example,  the  use  of 
the  TMS  in  autonomously  registering  XSDs  with  the  DDMR  and  the  benefits  gained  by 
registering  TMS  services  with  the  NCES  Service  Diseovery  Services. 
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Appendix  A.  Acronyms 


AFRL/IF 

Air  Eorce  Research  Laboratory,  Information  Directorate 

API 

Application  Programming  Interface 

COI 

Community  Of  Interest 

COT 

Cursor  On  Target 

DAG 

Directed  Acyclic  Graph 

DDMR 

DoD  Metadata  Registry 

DoD 

Department  of  Defense 

DOM 

Document  Object  Model 

GUI 

Graphical  User  Interface 

ICED 

Infosphere  Concept  Exploration  and  Development 

IDE 

Integrated  Development  Environment 

IMCS 

Information  Management  Core  Services 

MSR 

Metadata  Schema  Repository 

NCES 

Net-Centric  Enterprise  Services 

OIM 

Operational  Information  Management 

OWE 

Web  Ontology  Language 

PI 

Principal  Investigator 

RI 

Reference  Implementation 

SAX 

Simple  API  for  XML 

SDK 

Software  Development  Kit 

SOAP 

Simple  Object  Access  Protocol 

SOW 

Statement  of  Work 

SWT 

Standard  Widget  Toolkit 

TCP/IP 

Transmission  Control  ProtocoFInternet  Protocol 

TIM 

Technical  Interchange  Meeting 

TMS 

Type  Management  System 

URL 

Uniform  Resource  Locator 

WS 

Web  Services 

WSDL 

Web  Services  Definition  Language 

XML 

extensible  Markup  Language 

XMLDB 

XML  Database 

XSD 

XML  Schema  Definition 
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Appendix  B:  Analysis  Of  TMS  Extensions  To  Support 
OWL 

How  can  the  TMS  be  extended  to  support  the  capture  of  ontology  information  and  the 
generation  of  OWL  sehemas?  There  is  not  a  one-to-one  relationship  between  OWL 
schema  eonstruets  and  XSD  eonstructs.  Hence,  extending  the  TMS  tool  to  generate  OWL 
sehemas  is  not  simple.  Although  TMS  is  extensible,  the  ehallenge  will  be  to  add  the 
ability  to  eapture  desired  ontology  information  without  making  the  tool  unduly 
eomplieated.  Adding  ontologieal  funetionality  to  the  TMS  is  not  a  trivial  exereise,  but 
nothing  in  the  TMS  design  precludes  addition. 

Jena,  an  open-souree  Java  framework  for  building  applieations  under  the  semantie  web, 
might  be  useful  in  extending  the  TMS  to  support  OWL.  Jena  ean  be  used  with  Eelipse. 
Perhaps  a  “Generate  OWL”  menu  option  eould  be  added  to  the  TMS,  next  to  the 
eurrently  existing  “Generate  XSD”  menu  option.  The  “Generate  OWL”  menu  option 
would  invoke  the  Jena  models. 

An  example  illustrates  some  of  these  points.  Figure  B-1  presents  a  sample  of  Models, 
Fragments,  and  Elements  that  ean  be  defined  in  the  TMS.  Figure  B-2  presents  a  possible 
ontologieal  eharaeterization  of  this  example.  That  is.  Fragments  and  Elements  are 
explieitly  shown  as  elasses  in  the  ontology,  along  with  their  properties  and  relations 
among  instances  of  each.  The  possibility  of  this  sort  of  representation  justifies  the  elaim 
that  the  TMS  design  does  not  preelude  adding  OWL  funetionality.  Figure  B-2  eonstitutes 
an  outline  of  Jena  eode  for  ereating  a  model  from  which  an  OWL  schema  ean  be 
generated.  ITT  also  examined  Protege,  an  open-source  ontology  editor,  for  ideas  on 
generating  OWL  sehemas.  It  too  can  be  used  with  Eclipse.  It  was  installed  and  used  to 
define  simple  Elements  and  Fragments  from  whieh  an  OWL  sehema  was  generated. 

An  extension  of  the  TMS  to  support  OWL  would  also  need  to  reeonsider  how  Fragments 
and  Elements  are  stored.  These  are  currently  stored  as  XML  in  text  files.  The  structure  of 
this  XML  would  have  to  be  extended  to  provide  for  storage  of  additional  ontologieal 
information. 
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Model:  BaseLocation 
Description: ... 


Properties: ... 

Cr^ddress~ 


GeoLocation, 


Fragment:  Address 
Description:  ... 
Properties:... 
city 


Fragment:  GeoLocation 
Description:  Point 
Properties:  ... 


Element:  City 

,  Description:... 
Data  Type:  ... 

Element:  State 
•  Description:... 
Data  Type:  ... 

Element:  Lat 

Description:... 
Data  Type:  ... 

Element:  Long 

,  Description:... 
Data  Type: ... 


Figure  B-1:  An  Example  Model  For  The  TMS 


Datatype 

Properties 


Object 

Properties 


Properties 

Name - 

Type 

Desc  d 


hasElements- 


Ciasses 

Element  - 


•Fragments- 


instances 

Lat  < - 

Long<« - 

City  4 - 

State  < - 

-  Address - 

'^GeoLocation 


Figure  B-2:  A  TMS  Model  Interpreted  As  An  Ontology 
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OntModel  model  =  ModelFactory . createOntologyModel ( ) ; 
OntClass  element  =  model . createClass ()  ; 

OntClass  fragment  =  model . createClass ()  ; 
DatatypeProperty  name  =  model . createDatatypeProperty ( 
arguments  ) ; 

DatatypeProperty  type  =  model . createDatatypeProperty ( 
arguments  ) ; 

DatatypeProperty  desc  =  model . createDatatypeProperty ( 
arguments  ) ; 

Individual  lat  =  model . createindividual (  element  ) ; 
Individual  long  =  model . createindividual (  element  ) ; 
Individual  city  =  model . createindividual (  element  ); 
Individual  state  =  model . createindividual (  element  ) ; 
Ob j ectProperty  hasElements  = 

model . createObj ectProperty (  arguments  ) ; 

Ob j ectProperty  hasFragments  = 

model . createObj ectProperty (  arguments  ) ; 

//  hasFragments  is  not  used  in  this  example 
Individual  address  =  model . createindividual (  fragment 
) ; 

Individual  geoLocation  =  model . createindividual ( 
fragment  ) ; 

//  Ontology  classes  element  and  fragment  are  part 
//  of  model. 

//  Properties  name,  type,  and  desc,  and  their  values 
//  should  be  added  to  each  individual  element 
//  (lat,  long,  city,  state)  created  above. 

//  Property  hasElements  and  its  values  (city,  state) 

//  should  be  added  to  address 

//  Property  hasElements  and  its  values  (lat,  long) 

//  should  be  added  to  geoLocation 

Figure  B-3:  Jena  2.4  Code  Framework  Creating  An  Example  OWL  Model 
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Appendix  C:  ICED  Software  Catalog 


Component 

File 

Description 

TMS  GUI  and  Storage 

iced  1.0.0  src.zip 

Source  and  development  fdes 

icedl.O.O.zip 

Jar  file  and  TMS  data  files  to 
deploy  as  Eclipse  plugin 

IMS  Web  Services 

TMS-WS.zip 

Web  Services  to  deploy  under 
Tomcat 

Type  Management 
System.zip 

Source  and  development  files  for 
TMS  Web  Services  server  and 
client 

TMSClient.jar 

Default  Web  Services  client  to 
deploy 

Demonstration 

ICEDDemo.zip 

TMS  data  for  demonstration 

ICED  Final  Report 

ICEDFinalReprt.pdf 

This  document 
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